Template suggestions

[thomasballinger]

• Check auth on the server to know whether to wait for it on the client (instead of passing it in, both of these approaches discussed in Passing accessToken from server to client authkit-nextjs#286 (comment))
• Move ConvexClient to a provider to make above work
• Use an auth token for server components example to make it more realistic
• Change loading state machine based on suggestion in Bug: Incorrect loading state in ConvexClientProvider #5 (comment)
• Remove CONVEX_DEPLOY_KEY from example .env.local file since it should almost never be used locally, see docs

[cabyambo]

Love this refactor! Super clear.

One thing to point out is the call to withAuth here causes all children of the layout to be dynamic routes, removing the option for the more performant static routes.

[thomasballinger]

Great point, seems like we should be declaring routes/component trees as expecting auth instead of asking whether the user is authed to decide.

Ideally <Authenticated> could take care of this: <Authenticated> could render its children during SSR and on hydration when authed, or if we can't have that access token available (related issues) then at least know that auth is coming, and we can do a more localized version of expectAuth: true.

@nicknisi any plans to be able to check on the first render whether a route is authed, or more specifically whether an accessToken is coming?

[thomasballinger]

Seems like we want grouped routes here so we can use different layouts here, yea? app/(authed)/layout.tsx so it can be server-rendered

[nicknisi]

any plans to be able to check on the first render whether a route is authed, or more specifically whether an accessToken is coming?

@thomasballinger wondering if the changes in workos/authkit-nextjs#297 would help to simplify this?

[nicknisi]

@thomasballinger After some testing I made some minor tweaks in cd7d9a5 and upgraded to the latest authkit-nextjs in 1dc0978. I pushed them up to this PR.

[thomasballinger]

thanks!

[cabyambo]

Is this call to withAuth essentially instant since we already authenticated in the middleware.ts? Or does this make a server round trip, meaning we have a round trip in middleware followed by a second round trip here (on an already authenticated route)?

If it is the latter, would it make sense for us to switch the middleware.ts to page based auth instead of the current middleware auth? Middleware documentation.

[nicknisi]

Great question! the withAuth() call is essentially instant. It reads the session from a header that the middleware already set. There's no additional authentication or API call happening.

[cabyambo]

Ooh sweet. Thanks for the info!