-
Notifications
You must be signed in to change notification settings - Fork 267
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Next.JS UI Component Pop-In with SSR #1282
Comments
This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 10 days. |
I’d be interested to hear about this, I’ve also noticed the SSR pop-in. |
Currently clerk will only render components with client side rendering. You can review this from the network tab by filtering js documents only. |
This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 10 days. |
This issue was closed because it has been stalled for 10 days with no activity. |
This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs. |
Package + Version
@clerk/nextjs
@ 4.19.0Dependencies + versions
Browser/OS
Chrome / Windows
Description
I'm a new user of Clerk but not a new user of SSR, so I'm trying to piece all of this together -- apologies if I'm missing anything obvious! I love the idea of this application but am running into some unfortunate snags with server side props.
I'm using the
pages/
directory style of next.js and no matter what I try, I can't escape components like<UserButton />
or<OrganizationSwitcher />
popping in on the client. The requests seem to originate from here in the Clerk context provider: https://github.com/clerkinc/javascript/blob/main/packages/react/src/contexts/ClerkContextProvider.tsx#L88-L105From what I can tell, even if a fully inflated
initialState
is passed into the provider (inflated via SSR via this flow: https://clerk.com/docs/nextjs/getserversideprops), this isomorphic client still starts up on the client and fires off a request, and eventually the FE component loads.It looks to me like the intent is to not block on that FE request -- judging by this code here that tries to use SSR provided state where possible: https://github.com/clerkinc/javascript/blob/main/packages/react/src/contexts/ClerkContextProvider.tsx#L39-L79
In other words, it looks like the intent is to support hydration from SSR props, but the current implementation doesn't work. I've created a repo here that showcases the issue: https://github.com/Steven-Ireland/clerk-bug-issue
and here's a gif: (note how
useAuth()
consistently returns true, but the other ui components pop in after a refresh)There's a PR on that repo that shows only the relevant files: https://github.com/Steven-Ireland/clerk-bug-issue/pull/1/files
Thanks for taking a look!
The text was updated successfully, but these errors were encountered: