improvement(settings): remove the 300ms floor under settings section switches - #8435
Conversation
…switches
Every section switch mounted a fresh Suspense boundary (the empty section loading.tsx and a page-level <Suspense fallback={null}> around the code-split body). React 19 holds content that resolves into a just-committed fallback for at least 300ms, so every switch paid that before the section even rendered or started its queries.
- drop the section loading boundaries and page-level Suspense on all settings planes; navigations are transitions, so the outgoing section stays until the incoming one is ready
- move the sidebar selection on click so the click still reads as acknowledged
- warm each hot section's first-content queries on navigation intent
- load the fork sync editor and custom tool editor on open; they pulled the block and trigger registries into the list chunks
|
The latest updates on your projects. Learn more about Vercel for GitHub. |
|
There was a problem hiding this comment.
All reported issues were addressed across 20 files
Reply with feedback, questions, or to request a fix.
Fix all with cubic | Re-trigger cubic
The pending row cleared only on a pathname change, so a navigation the server redirected back to the current section, or one that failed, left the clicked row selected and its click guard swallowing retries. Set the selection optimistically inside the navigation's own transition so React drops it when that transition settles.
|
@cubic-dev-ai review this PR |
@waleedlatif1 I have started the AI code review. It will take a few minutes to complete. |
Summary
loading.tsx, plus a page-level<Suspense fallback={null}>around the code-split body. React 19 holds content that resolves into a just-committed fallback until 300ms after that fallback appeared, so the body, its chunk and its queries all queued behind that floorloading.tsx(workspace + org) and the page-level Suspense on all four settings planes. Navigations are transitions, so the outgoing section stays on screen until the incoming one is ready. The boundary can't be hoisted into the settings layout: that would wrap the[section]layout, where 404 and legacy 307 are decided, and both would turn into 200usePendingSettingsSelection, cleared on any pathname change), so the click is still acknowledged immediatelyqueryOptionsfactories for those hooks; behavior is unchanged apart fromretryOnMount: true, per the prefetch-on-intent ruleloading: () => nullso they have their own boundaryType of Change
Testing
integrations/privacybun run --cwd apps/sim testover settings, sidebar, hooks/queries and workspace-forking: 108 files / 648 tests passbun run lint,bun run type-check,check-block-registry,bun run check:audits(52 audits),docs-manifest:checkloading.tsxentry is dropped from the baselineChecklist
test-auditauthoring gate)