fix(settings): wrap useSearchParams pages in Suspense so navigation works in prod#399
Merged
Conversation
… prod
The settings page derived its active panel from `useSearchParams()` but
wasn't wrapped in a Suspense boundary. In Next 16 that fails the
production build ("missing Suspense with CSR bailout") and forces the
page to bail to full client-side rendering — shipping a settings screen
whose rail click handlers never wire up. Because the account-menu
Settings link targets `?tab=whatsapp`, users land on the WhatsApp panel
and can't navigate to any other section ("locked on WhatsApp").
Wrap the `useSearchParams` consumer in `<Suspense>` on the three
affected dashboard pages — settings, inbox, automations/new — mirroring
the split login/signup already use. Also add the missing
`Settings.sections.quick-replies` label, which was rendering as a raw
translation key in the settings rail.
Verified: production build now succeeds (previously errored out during
static generation); every settings rail section navigates correctly in a
production build.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
|
This pull request has been ignored for the connected project Preview Branches by Supabase. |
7 tasks
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.
What & why
Opening Settings → WhatsApp (e.g. via the account menu, which links to
/settings?tab=whatsapp) left the page locked on the WhatsApp panel — clicking any other rail section did nothing.Root cause
The settings page derives its active panel from
useSearchParams()but wasn't wrapped in a<Suspense>boundary. In Next 16 that:useSearchParams() should be wrapped in a suspense boundary … missing-suspense-with-csr-bailout, andSince the entry link targets
?tab=whatsapp, you land on WhatsApp and can't leave.next devrenders on-demand and papers over this, so it only shows up in a production build/deploy.login/signupalready wrapuseSearchParamsin<Suspense>;settings,inbox, andautomations/newdid not — so all three broke the build.Changes
useSearchParamsconsumer in<Suspense>on settings, inbox, and automations/new (thin wrapper +*Innercomponent, matching login/signup).Settings.sections.quick-repliestranslation key (the rail was rendering the raw keySettings.sections.quick-replies).Verification
next builderrors out during static generation on these pages.next buildsucceeds (✓ Generating static pages 51/51); ran the production server and confirmed every settings rail section navigates to its correct panel, and the rail shows "Quick replies".Follow-up (not in this PR)
The WhatsApp panel's setup-instruction strings (
Settings.whatsapp.step3_2…step4_4) embed<strong class="…">insidedangerouslySetInnerHTML={{ __html: t(...) }}, which next-intl can't parse (INVALID_TAG) — cosmetic, tracked separately.🤖 Generated with Claude Code