perf(board): server-render board layout and deduplicate fetches#5770
perf(board): server-render board layout and deduplicate fetches#5770ajnart wants to merge 9 commits into
Conversation
…cted When adding a widget from the "Choose item to add" modal, the widget edit modal now opens immediately after placement, allowing the user to configure options and integrations before the widget renders. All available integrations for the widget are selected by default.
Split board rendering into two modes: a static CSS Grid for view mode (SSR-friendly, no JS required for layout) and a lazy-loaded GridStack for edit mode. This eliminates widget "pop-in" on page load by rendering the full grid layout server-side.
Add useOptionalSectionContext to gracefully handle rendering outside GridStack (view mode). The item menu now uses optional chaining for gridstack access instead of throwing when context is absent.
Provide estimated width/height to widgets before useElementSize measures the DOM, preventing responsive breakpoint shifts during hydration. Replace the Loader spinner with a Skeleton for widget loading states.
Prefetch weather and RSS feed data during SSR so widgets render with content on first paint instead of showing loading states.
Dokploy Preview Deployment
|
Dokploy Preview Deployment
|
# Conflicts: # apps/nextjs/src/app/[locale]/boards/(content)/_client.tsx
Remove useIsBoardReady and LoadingOverlay from edit mode board, aligning with the dev branch's perf improvement that shows the board immediately without waiting for ready state.
Wrap getInitialBoardAsync in React cache() so the same board data is fetched once per request instead of 3 times (layout, page, metadata). This is the same pattern used for auth() in the codebase.
|
I see a few problems with these changes, especially regarding the server rendering. If you open the default board right now it loads with smaller texts and 11:45 as time because it uses the server local time and a predefined screen size, therefore we have to decide if we really want these changes or if we are okay with it loading on the client, but at least showing it without layout shift & wrong data |
I agree there are some drawbacks, maybe it's more of a proof of concept stage right now. I do really like the idea of having the edit mode as a whole separate thing that loads up gridstack for re-organizing and then just having a simpler read-only dashboard in view mode |
|
Yeah I also already though about spliting it even from an url standpoint. Similar to confluence where you go into edit mode and it sends you to a different url than the page you can view it |
I wouldn't necessarily create another page, ideally it's possible to leverage dynamic imports like we did for integrations so that it only loads on demand |
|
I'll convert it back to draft as it is currently a poc |
Summary
useElementSizehasn't measured yetHow it works
_dynamic-client.tsxno longer wrapsClientBoardindynamic(..., { ssr: false })— the board now renders on the serverstatic-grid.tsx) with container queries to match GridStack's square-cell sizingnext/dynamicwithssr: falseuseEditMode()returnsfalseduring SSR, so the static grid always renders server-sideTest plan