You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I need the lang attribute on <html> to reflect the authenticated user's locale preference (stored in Redis/DB), resolved per-request during SSR. This is extremely important to me.
What I've considered
1. Middleware
createMiddleware runs for every request — including API routes and potentially static assets depending on the deployment target. Running a Redis/DB lookup unconditionally on non-page requests is not acceptable.
Path-based filtering (skip /api/*, skip paths with file extensions) works but relies on conventions that feel fragile rather than architecturally guaranteed.
2. Cookie (current approach)
Reading a locale cookie synchronously in the document function works and has zero overhead. The limitation: cookies can be stale across devices. If the user changes their locale on Device A, Device B's cookie won't update until the next login or an explicit refresh.
For <html lang> this may be acceptable — but I'd like to understand if there's a better option.
3. createAsync inside the document function
The document prop in <StartServer> is a SolidJS component rendered during SSR, so it should be able to use createAsync / cache:
Does createAsync inside document suspend correctly and resolve before the HTML stream begins?
The element is the outermost node — is wrapping it in safe, or does it break streaming semantics?
What I'm looking for
Is there an officially supported pattern for resolving async server data in entry-server.tsx's document shell, with the guarantee that it only runs for HTML page renders (not API routes, not static assets)?
Or is the intended pattern to pre-populate event.locals from the route load function and read it synchronously in document?
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
-
Context
I need the
langattribute on<html>to reflect the authenticated user's locale preference (stored in Redis/DB), resolved per-request during SSR. This is extremely important to me.What I've considered
1. Middleware
createMiddlewareruns for every request — including API routes and potentially static assets depending on the deployment target. Running a Redis/DB lookup unconditionally on non-page requests is not acceptable.Path-based filtering (skip
/api/*, skip paths with file extensions) works but relies on conventions that feel fragile rather than architecturally guaranteed.2. Cookie (current approach)
Reading a
localecookie synchronously in thedocumentfunction works and has zero overhead. The limitation: cookies can be stale across devices. If the user changes their locale on Device A, Device B's cookie won't update until the next login or an explicit refresh.For
<html lang>this may be acceptable — but I'd like to understand if there's a better option.3.
createAsyncinside thedocumentfunctionThe
documentprop in<StartServer>is a SolidJS component rendered during SSR, so it should be able to usecreateAsync/cache:Questions:
What I'm looking for
Is there an officially supported pattern for resolving async server data in entry-server.tsx's document shell, with the guarantee that it only runs for HTML page renders (not API routes, not static assets)?
Or is the intended pattern to pre-populate event.locals from the route load function and read it synchronously in document?
Related: solidjs/solid-meta#6
Beta Was this translation helpful? Give feedback.
All reactions