Can I use Server Component with a global Context? #42301
Replies: 10 comments 38 replies
-
|
As I understand it what you're doing should theoretically work. You can have client components that take server components as children. See https://github.com/reactjs/rfcs/blob/main/text/0188-server-components.md#capabilities--constraints-of-server-and-client-components |
Beta Was this translation helpful? Give feedback.
-
|
But does it mean that these server components are rendered as client components? So have their JavaScript shipped to the browser? |
Beta Was this translation helpful? Give feedback.
-
|
This would interest me too!!! |
Beta Was this translation helpful? Give feedback.
-
Doesn't seem like it. Docs say:
|
Beta Was this translation helpful? Give feedback.
-
|
UPDATE: I was previously spreading misinformation that I've once heard from Vercel employees, among others. I have performed a test to settle the misunderstanding. I have run the test on local dev, local prod build and vercel prod build. This is a screenshot of what HTML the browser receives as part of the initial document, with JS disabled. The data inside of the blue component is stuff that I fetch from a local JSON file on the disk - it is a server component.
To take things further:
|
Beta Was this translation helpful? Give feedback.
-
|
Nice. Thank you! @krall12 |
Beta Was this translation helpful? Give feedback.
-
|
I asked the same question in regards to i18n this week on Twitter: https://twitter.com/jamannnnnn/status/1587835293989732352. It seems to me like having to switch to client components to be able to use context is very much at odds with enabling as many components as possible to stay on the server side. I'm currently looking for such a capability in order to bring RSC support to |
Beta Was this translation helpful? Give feedback.
-
|
We now have documentation on Context: https://beta.nextjs.org/docs/rendering/server-and-client-components#context |
Beta Was this translation helpful? Give feedback.
-
|
Hey Lee, thanks for mentioning this here! I have to say though that the i18n use case still seems a bit hard to achieve with the presented guidelines. The main issue I'm seeing is that with the currently available options, this forces many components to be marked for the client side, which could otherwise remain server-only. The docs mention that React Context is typically used for data that changes over time, but I think for the i18n use case this is not true.
EDIT 2: Reading params deeply would solve this problem without context: #58862 Thank you! 🙂 |
Beta Was this translation helpful? Give feedback.
-
|
|
Beta Was this translation helpful? Give feedback.
-
|
Getting access to requestAsyncStorage would be great, I'd like to have it too 😕 |
Beta Was this translation helpful? Give feedback.
-
|
@amannn ouch. so they didnt communicate even with someone like you lol
|
Beta Was this translation helpful? Give feedback.
-
|
@markomitranic Yep, next-intl currently uses a workaround. I hope that some form of this will land: #58862 |
Beta Was this translation helpful? Give feedback.
-
|
I've made a small utility for this using |
Beta Was this translation helpful? Give feedback.
-
|
I copied your idea and made a custom hook - https://dev.to/jdgamble555/easy-context-in-react-server-components-rsc-1mdf |
Beta Was this translation helpful? Give feedback.
-
|
I also think it'd be nice to see a per request server context made available in some form. I'm new to Next and was pretty baffled that the docs discount the need. There are plenty of uses beyond i18n. For example, I tried to build a serverside caching singleton (the suggested fetch/cache solution or prop drilling is simple for my needs) but ran up against a wall trying to keep it alive from beginning to end of a request (and not persist between requests). |
Beta Was this translation helpful? Give feedback.
-
|
See my answer above: https://www.npmjs.com/package/server-only-context |
Beta Was this translation helpful? Give feedback.
-
|
Hey I did check that out, but the way it's set up in the example won't anything set to serverContext() persist between requests and possibly leak unwanted data? My singleton works in a similar way, but with the idea of cleaning its state on each request. The problem is when I try to do the cleaning in the root layout.ts, it sometimes gets run multiple times during the request (thus cleaning the cache too soon). In a related issue, I've noticed that while layout.ts is the first component to be called, React continues to render children (page.ts, etc.) before any promises inside layout resolve. Since I'd like some root data to be avail regardless of route, and I prefer to call it in a single place it seems I'm out of luck. Would be nice to have an entry point where you could temporarily block rendering if needed. If I understand this new paradigm correctly, I guess the idea is to discourage this in order to let async streaming do its work. Still best to err on the side of flexibility IMO. |
Beta Was this translation helpful? Give feedback.
-
|
That's not the case @unleashit as it uses |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for the reply. If that's the case, then I imagine it must work because React's cache() has access to the request lifecycle behind the scenes. It would be nice if that access wasn't black boxed and we were provided a way to hook into it ourselves. Not sure if it's planned, or if they've just determined it a foot gun without a valid use. |
Beta Was this translation helpful? Give feedback.
-
|
Hello! We have some documentation here on recommended patterns for using React Context: https://beta.nextjs.org/docs/rendering/server-and-client-components#context |
Beta Was this translation helpful? Give feedback.
-
|
Hey @leerob! Is there any roadmap or similar to follow along with the development of I do understand that you'd want to use regular React Context for most cases, but seems like there are valid cases for |
Beta Was this translation helpful? Give feedback.
-
|
Hey thanks for chiming in. I've seen those docs, but I guess some of us would like to do things that are not necessarily the recommended pattern. I get that Server Components can have a couple of different contexts: 1. as part of an initial full page load and 2. a later update from the client (as far as I know, the future plan is to allow the component to be individually called?). So I can see the problem of having code be aware more than one context. In addition, new things that get added to context could be ignored once streaming begins (which could requiring some blocking if those things are important). Still, I would much prefer easy access to req and res (and/or the Node Async Context) and accept the complexity tradeoff. While it would be easier to access context (on the server directly), I found I was able to achieve what I wanted with React.Cache. At least in my testing so far, I'm able to cache a singleton instance (redux store, etc.) and have it be replaced at new requests as I'd expect. Are there other hidden gotchas besides the ones I mentioned to why you don't seem to want to support this? |
Beta Was this translation helpful? Give feedback.
-
|
@leerob Does those docs have a new home? That link doesn't work anymore. |
Beta Was this translation helpful? Give feedback.
-
|
This became a blocker for us just recently. We're aiming to build an architecture where our standalone component library only depends on a generic data provider interface without binding to any specific implementation. Each environment where the component library is then used (including but not limited to NextJS projects) would provide their own implementation of the data provider. A similar need exists when it comes e.g. to theming or even the link component implementation (given that NextJS apps benefit from NextJS links, but other apps might use something else). Originally we set out to use context for this, but as others already noted it won't work on the server. Here's a workaround that seemed to work so far, although it is somewhat cursed and might lead to rehydration issues down the line if we're not careful, as we now can provide a different data provider instance on the client & server (which could lead to different rendering results between the two): thunderstore-io/thunderstore-ui#744 I don't particularly like having to implement a workaround in the first place, it'd be great if NextJS would support something to enable the kind of pluggable architecture we're looking to implement. |
Beta Was this translation helpful? Give feedback.
-
|
Ran into this as well when trying to build a feature flagging SDK, which requires a shared "context" for the duration of the request that can hold the current user and flag configuration data. The solution I ended up landing on was basically to "curry" the whole interface of the SDK via a setup function that defines how to obtain the user for the current request. You can see that in action here and view the source code implementation here. It basically looks like this // export "curried" functions that are scoped to use the options passed here
export const { getVariableValue } = setupDevCycle({
sdkKey: 'some-key',
userGetter: async () => {
const userIdentity = headers().get('user-id')
return {
user_id: userIdentity
}
}
})The reason this works is that all the methods that are exported from that setup function end up calling an "ensure initialization" function which performs things like fetching the current configuration and current user data according to the configured options. It then memoizes the results using the React Now the interface within a server component becomes: // import the "curried" function from the file where the setup function is called
import { getVariableValue } from './devcycle'
export default async ServerComponent() {
// this function can be called with just the details of the flag we want to evaluate. It already knows the current user's data and
// what the flagging configuration is
const variableValue = await getVariableValue('someKey', false)
// do something with the value
}Hopefully this helps someone, I was stuck on this for a while. |
Beta Was this translation helpful? Give feedback.
-
|
@markomitranic from my understanding the reason that |
Beta Was this translation helpful? Give feedback.
-
I get that this can be a foot gun, but maybe enable with a flag? This is the minimum I would need to look at next.js again personally. |
Beta Was this translation helpful? Give feedback.
-
|
I think it also has something to do with Next being able to use static analysis to determine whether a page can be statically rendered (ie. any page that doesn't import headers, cookies etc. is safe to be static). |
Beta Was this translation helpful? Give feedback.
-
|
Could that be solved by allowing to opt out of automatic detection? If the dev doesn't have the settings right, it's their fault? I do get that's it's complicated (and amazing) to provide all the feature's Next provides. That said, using it felt like 5 steps forward and 10 steps back after using other React SSR frameworks (that granted ONLY did SSR, but didn't get in the way constantly with strong opinions). |
Beta Was this translation helpful? Give feedback.
-
|
I think another reason they don't allow it is that not every request to the backend is the same "type" of request. On clientside nav the browser is sending a request that's basically asking for a partial update of the server-rendered content. Those details are abstracted behind the helpers like On the other hand there definitely seems to be an ongoing debate about "performance by default" vs. "expose more details and let developers do it". One other example is the current monkeypatching the framework does on the |
Beta Was this translation helpful? Give feedback.
-
|
Exactly today I struggled with a similar challenge. After only studying the docs (@leerob linked to them) I was even more confused. The docs are excellent in my opinion and they get better almost every day. Forgive me, if I missed the point, I did not read the whole conversation, but I'll focus now on the initial post. @hucancode said:
Right, but to "switch back" to React Server Components, you have this "slot pattern" Supported Pattern: Passing Server Components to Client Components as Props, which is not helpful at the first view. To use React Context you place a custom client context provider in your RootLayout, or somewhere close to the component root. But now everything enclosed in this lets say Yes and no. This is not true for PageComponents So you still can continue with nested pages as Server Components and access the context in even deeper nested client components. But what, if you want to access the Context in a Server Component? You use this "slot pattern" and forward the context values as props to the React Server Component. This was a "quicky", so hopefully did not oversee things. @leerob You have this very helpfull "Good to know" sections in the docs. If It is not just me, who was a bit confused by the fact that Client Components can not import Server components, perhaps it's worth adding a hint. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for the link @markomitranic. That's interesting. But I don't see how this helps in the context of "switching between or combining" Client Components and Server Components. Perhaps we are talking about different things? Part of the initial question I reference to:
|
Beta Was this translation helpful? Give feedback.
-
|
I understand the confusion, the first question was a bit too broad and asked 2 questions in one without knowing it :)
This is not true, as shown in previous comments and in the Next.js docs. A server component can be rendered on the server, or statically, and served as a child of a client component when passed as params. This leaves us only with the second question:
This is what I was responding to - on the client you simply use a context to have a global context - on the server you use the cache trick in all your layouts and pages, which gives you the same functionality, the ability to set data globally during a request and share it between components. A good example of this is To answer a third question, that nobody asked yet, but will - no, it is not possible to share context data between client and server. You can set it individually, or share it unidirectionally from server to the client, but not the other way around. Edit: formatting fix |
Beta Was this translation helpful? Give feedback.
-
|
I think the way to think of it is that if you want a context shared between the whole tree (server and client) then it's the server that needs to own that context, not the client. In the docs for my library I linked in the above comment you can see how the serverside context setup returns a function |
Beta Was this translation helpful? Give feedback.
-
|
Thanks and I finally undertsand this part. In this article Supported Pattern: Passing Server Components to Client Components as Props, it declare something:
For the conclusion 2, the server component will still works as the server-rendered component, so you don't need to worry about that. And I really can't remember where does this idea come from, that a server component wrapped by client component will be rendered as client component anyway, maybe the original idea is comes from the conclusion 1. And for the conclusion 1, this is normal if you have build a server component, but you use it in a parent client component, which can be like a menu or list that needs React. At this time you should receive an issue. So for this discussion, if you have built some providers, like zustand, next-themes or next-intl and so on, it will be normal that they declare that they are client components, but they will not influence your children server components in layout. And we can do a simple test, in my code, I use zustand, mui, shadcn/ui and next-intl and so on: <html suppressHydrationWarning>
<CommonStoreProvider>
<AppRouterCacheProvider options={{ key: "css" }}>
<NextIntlClientProvider messages={messages}>
<ThemeProvider
attribute="class"
defaultTheme="system"
enableSystem
>
<MuiThemeProvider theme={theme} defaultMode="system">
<CssBaseline />
{children}
<LayoutClient />
</MuiThemeProvider>
</ThemeProvider>
</NextIntlClientProvider>
</AppRouterCacheProvider>
</CommonStoreProvider>
</body>
</html>And I didn't decalre <>
<LandingMainArea locale={locale}></LandingMainArea>
<LPClient locale={locale}></LPClient>
</>
export default async function LandingMainArea({ locale }: Props) {
// RSC solution from next-intl
const t = await getTranslations("Common");
// zustand store provider which works under react context
const {
globalExtendPopupOption,
setGlobalExtendPopupOption,
goExtend,
setClientReady,
goFeatureCheck,
} = useCommonStore((store) => ({
globalExtendPopupOption: store.globalExtendPopupOption,
setGlobalExtendPopupOption: store.setGlobalExtendPopupOption,
goExtend: store.goExtend,
setClientReady: store.setClientReady,
goFeatureCheck: store.goFeatureCheck,
}));
return (
...And you will see this issue definitely: In case you get confused again later on, if you are not sure where your server component is working, you can just add some client-side codes to see if they will cause errors. |
Beta Was this translation helpful? Give feedback.
-
And I think for the client component import RSC part, if your RSC is easy and not using some features from RSC (like async/await), you won't receive the error and Next.js will downgrade it to the normal client component. That's should be where the idea comes. |
Beta Was this translation helpful? Give feedback.
-
I am seeing the whole point of Server Component is that it gets rendered on the server. But what if I want to implement i18n, or theme context, or anything that requires having a global context.
Take this
app/layout.jsxfor example, I want to have anI18ncontext available site-wide, so I can translate whatever text whenever I want.The
I18ncomponent is implemented as so, usingcreateContext, I am forcing myself to abandon Server Component.As what I understand, this approach forces almost everything to be client component, child of a client component has to be client component, right?
Do we have any solution to implement global context but still render on server whenever possible?
Beta Was this translation helpful? Give feedback.
All reactions