Add Data Loading States to Management Tables

[Lakes41]

Difficulty: Advanced

Type: Refactor

Summary

Add consistent loading, empty, error, and retry states to dashboard management tables so failed or slow requests do not silently fall back to stale mock data.

Current Behaviour

Pages such as passes and members initialise from mock data, then fetch API data inside useEffect. If a fetch fails, the page logs a warning and continues showing the initial mock records. This makes it difficult for users to know whether they are viewing current data, fallback data, or failed live data.

Expected Behaviour

Management pages should clearly communicate data loading state. Users should see loading skeletons, empty states, explicit errors, and retry actions where appropriate. Mock fallback should be labelled when used intentionally.

Suggested Implementation

Create reusable table state components for loading, empty, error, and fallback notices. Update passes, members, guilds, activity, and dashboard summary sections to use these states. Track whether data came from the API, mock fallback, or local initial state. Add retry handlers for failed requests.

Files or Areas Likely Affected

• apps/dashboard/app/dashboard/page.tsx
• apps/dashboard/app/passes/page.tsx
• apps/dashboard/app/members/page.tsx
• apps/dashboard/app/guilds/page.tsx
• apps/dashboard/app/activity/page.tsx
• apps/dashboard/components/
• apps/dashboard/test/

Acceptance Criteria

• Passes table shows a loading state before API data resolves.
• Members table shows a loading state before API data resolves.
• Empty API responses show intentional empty states.
• Failed API requests show visible error states with retry actions.
• Mock fallback is clearly labelled when used.
• Tests cover loading, empty, error, retry, and fallback states.

Additional Notes

This issue should not change the backend data model. It only improves client state clarity and user trust.

[Franlinozz]

Hi, I’d like to work on this issue. I’m comfortable with React/TypeScript dashboard flows and I’ll keep the refactor focused on the management table state handling.

My approach will be to first review the existing fetch/useEffect patterns across the dashboard pages, especially passes, members, guilds, activity, and the dashboard summary sections. Then I’ll add a small shared set of reusable table state components for loading, empty, error, and mock-fallback notices so the logic is not duplicated across pages.

I’ll make sure API requests show a stable loading state before data resolves, empty API responses render intentional empty states, failed requests show visible error messages with retry actions, and any mock fallback is clearly labelled instead of silently appearing as real data. I’ll preserve the existing table layout and avoid unnecessary UI changes.

Before opening the PR, I’ll run the project’s lint/test/build checks and include the results clearly in the PR description.

[Phantomcall]

Hi! I'd like to take on this refactor.

My implementation plan is to:

• Create reusable UI state components for loading, empty, error, and mock fallback states under apps/dashboard/components/ to keep the behavior consistent across the dashboard.

• Update the Dashboard, Passes, Members, Guilds, and Activity pages to use these shared components instead of silently displaying stale mock data.

• Introduce explicit client-side state tracking so each page knows whether its data came from:

  • the live API,
  • intentional mock fallback, or
  • the initial local state.

• Add retry handlers for failed requests, allowing users to fetch fresh data without refreshing the page.

• Ensure loading skeletons are displayed while API requests are in progress, empty responses show clear empty states, and any intentional fallback data is visibly labelled so users understand what they're viewing.

• Add tests covering the loading, empty, error, retry, and fallback scenarios to prevent regressions.

I'll keep the scope limited to the frontend state management and UI, without modifying the backend data model or API behavior. If someone is already working on this issue, please let me know before I begin.

Thanks!

[Promise278]

i have expereinced with system designs and archecture i would love to work on these please

[leocagli]

Hi — Leo Cagliero here (Starmaker program, currently building on Cosmos LATAM and Open Stellar).

I traced the exact root cause. In apps/dashboard/app/passes/page.tsx (and the identical block in app/members/page.tsx), PassesPage seeds useState<MockPass[]>(mockPasses) and the useEffect load() swallows failures with console.warn("Falling back to mock passes:", err) — so a failed /api/passes fetch silently renders mock rows as if live.

My fix keeps that load() but adds explicit status so the table can branch:

type Source = "loading" | "api" | "mock" | "error";
const [source, setSource] = useState<Source>("loading");
// in load(): setSource("api") on ok+Array; in catch: setSource("error");

Then I'll add reusable components under apps/dashboard/components/ — TableSkeleton.tsx, ErrorState.tsx (with a retry prop that re-invokes load()), and a FallbackNotice.tsx banner — reusing the existing EmptyState.tsx for empty API responses. The table body renders skeleton while loading, ErrorState on error, EmptyState when api returns [], and the labelled fallback banner only when mock is intentional. Same wiring applied to guilds, activity, and the dashboard summary.

I'll cover loading/empty/error/retry/fallback in apps/dashboard/test/ following the existing optimistic.test.ts / members.test.ts style, no backend/data-model changes.

Could you assign this to me? I can turn the PR around quickly.

[grantfox-oss]

🦊 GrantFox — @Franlinozz has been assigned to this issue as part of the Official Campaign campaign!

Next steps:

1. Open a Pull Request referencing this issue (e.g., Closes #81)
2. Your PR will be reviewed by the Adamantine-guild maintainers

Good luck! Track your progress on GrantFox.