Migrate data loading to Server Components - #3
Merged
Conversation
Convert the authenticated pages from client-side useEffect fetching to Server Components that fetch initial data and hydrate the Zustand store, eliminating the per-navigation loading spinners and enabling SSR. - Dashboard, board, and calendar pages are now async Server Components that fetch data server-side (getBoards / getBoard + getBoardData + members / getCalendarCards) and pass it down. - Add thin client hydrators (DashboardClient, BoardClient) that seed the store synchronously before the interactive components render. BoardClient is keyed by boardId so switching boards remounts and re-seeds; it also upserts the board record so the Navbar title works on direct deep-links. - Split the calendar into a server page + CalendarView client component (deadlines serialized to ISO strings for stable client parsing). - Convert the authenticated layout to a Server Component that performs the auth check server-side and renders a new AppShell client component, removing the isPending shell spinner. Navbar takes the user as a prop instead of useSession so the header is correct during SSR. - Dashboard accepts currentUserId from the server so the owned/shared split is correct on first paint (no hydration mismatch). - Add getBoard(boardId) server action for single-board fetches. Verified: next build compiles all routes; dashboard/board/calendar are now server-rendered on demand. tsc clean. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
The big architectural change from the frontend analysis: migrate initial data loading from client-side
useEffectfetching to Server Components. Pages now fetch data server-side and hydrate the Zustand store, so the per-navigation loading spinners are gone and content is server-rendered.Before
Every authenticated page was
''use client''and fetched its data inuseEffectafter mount -> a spinner on every navigation ("Loading Dashboard...", "Opening board...", "Synchronizing..."), request waterfalls, no SSR.After
DashboardClient,BoardClient) seed the store synchronously before the interactive components render.BoardClientis keyed byboardId(remount + re-seed on board switch) and upserts the board record so the Navbar title works on direct deep-links.CalendarViewclient component (deadlines serialized to ISO strings for stable parsing).AppShellclient component - removes theisPendingshell spinner.Navbartakesuseras a prop instead ofuseSession, so the header is correct during SSR.currentUserIdfrom the server so the owned/shared split is correct on first paint (avoids a hydration mismatch).getBoard(boardId)server action for single-board fetches.Route table after build
(previously client-only shells)
Verification
next build-> compiles all 7 routes, collects page data successfullytsc --noEmit-> exit 0/,/login,/signup-> 200;/dashboard,/calendar,/board/:id-> 307 ->/login(proxy + server-side auth guard both active)Notes
proxy.tsedge guard is kept as first-line defense; the server layout adds a second server-side check.Generated with Claude Code