Can I use Server Component with a global Context? #42301

hucancode · 2022-11-01T13:52:50Z

hucancode
Nov 1, 2022

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.jsx for example, I want to have an I18n context available site-wide, so I can translate whatever text whenever I want.

    <html>
      <body className="page-container">
        <I18n lang={lang} dictionary={dictionary}>
          <Navbar />
          <main>{children}</main>
          <FootNote />
        </I18n>
      </body>
    </html>

The I18n component is implemented as so, using createContext, I am forcing myself to abandon Server Component.

"use client";
import { createContext, useContext } from "react";
import rosetta from "rosetta";
export const I18nContext = createContext();
const i18n = rosetta();
export default function I18n({ lang, dictionary, children }) {
  i18n.set(lang, dictionary);
  i18n.locale(lang);
  return <I18nContext.Provider value={i18n}>{children}</I18nContext.Provider>;
}

export function useI18n() {
  return useContext(I18nContext);
}

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?

krall12 · 2022-11-01T14:18:05Z

krall12
Nov 1, 2022

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

4 replies

oliviertassinari Dec 1, 2022

But does it mean that these server components are rendered as client components? So have their JavaScript shipped to the browser?

felixhaeberle Dec 2, 2022

This would interest me too!!!

yakhinvadim Dec 4, 2022

But does it mean that these server components are rendered as client components? So have their JavaScript shipped to the browser?

Doesn't seem like it. Docs say:

React will know it needs to render on the server before sending the result (which doesn't contain any server-only code) to the client. From the Client Component's perspective, its child will be already rendered.

https://beta.nextjs.org/docs/rendering/server-and-client-components#importing-server-components-into-client-components

markomitranic Jan 19, 2024

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:
If we look at the HTML of the document we will see a bunch of embeded JS/JSON content near the bottom. We can easily identify that the render result corresponding to the server component is stored here as JSON, and will be used during re-rendering of the outer client component. Yes, not the code of the server component, instead a static result of the code that was executed on the server.

hucancode · 2022-11-02T00:00:07Z

hucancode
Nov 2, 2022
Author

Nice. Thank you! @krall12

0 replies

amannn · 2022-11-04T07:55:06Z

amannn
Nov 4, 2022

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 next-intl, an i18n library I'm maintaining.

0 replies

leerob · 2022-11-06T03:02:53Z

leerob
Nov 6, 2022
Maintainer

We now have documentation on Context: https://beta.nextjs.org/docs/rendering/server-and-client-components#context

5 replies

amannn Nov 7, 2022

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.

~~Have you considered one of these approaches?~~

createServerContext currently creates a context object that is automatically passed to the client-side as far as I can tell. Have you considered changing it to do the inverse, i.e. only being available on the server side? Based on the naming that's what I thought it might do. For auto-passing context to the client, maybe there could be createClientContext or just the existing createContext?
A request-level object, like context in GraphQL resolvers. This is not hierarchically available like React Context, but instead something that can be instantiated once per request and then be available everywhere. E.g. initialization in a middleware and then having a function like context() (similar to headers()) would be ideal IMO.

EDIT: The currently proposed createServerContext API would work for the i18n use case (based on the limited information that's currently available), by only moving the locale there and then using it to resolve other i18n config via React.cache. Would be great if createServerContext is supported in Next.js!

EDIT 2: Reading params deeply would solve this problem without context: #58862

Thank you! 🙂

amannn Nov 15, 2022

@leerob Any chance we could get access to requestAsyncStorage via a public API? This would work 😬: https://github.com/amannn/next-intl/blob/9365fe614a557eff3bbfa67c1d170bcab4125826/packages/example/src/utils/Storage.tsx

raphaelbadia Jun 16, 2023

Getting access to requestAsyncStorage would be great, I'd like to have it too 😕

markomitranic Jan 15, 2024

@amannn ~~what did you end up using? I’m looking at a use case similar to yours where the value isnmt expected to change and I purely wish to prevent prop drilling for locale string.~~

ouch. so they didnt communicate even with someone like you lol

How does unstable_setRequestLocale work?
next-intl uses cache() to create a mutable store that holds the current locale. By calling unstable_setRequestLocale, the current locale will be written to the store, making it available to all APIs that require the locale.

amannn Jan 16, 2024

@markomitranic Yep, next-intl currently uses a workaround. I hope that some form of this will land: #58862

manvalls · 2023-02-14T22:11:36Z

manvalls
Feb 14, 2023

I've made a small utility for this using cache:
https://www.npmjs.com/package/server-only-context

1 reply

jdgamble555 Oct 10, 2023

I copied your idea and made a custom hook - https://dev.to/jdgamble555/easy-context-in-react-server-components-rsc-1mdf

unleashit · 2023-02-15T02:56:23Z

unleashit
Feb 15, 2023

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).

4 replies

manvalls Feb 15, 2023

See my answer above: https://www.npmjs.com/package/server-only-context

unleashit Feb 16, 2023

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.

manvalls Feb 16, 2023

That's not the case @unleashit as it uses cache under the hood, which means the set value is only valid during the request, and it works even when handling several requests in parallel at the same time, each one having its own independent value.

unleashit Feb 16, 2023

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.

leerob · 2023-04-20T18:59:32Z

leerob
Apr 20, 2023
Maintainer

Hello! We have some documentation here on recommended patterns for using React Context: https://beta.nextjs.org/docs/rendering/server-and-client-components#context

3 replies

amannn Apr 20, 2023

Hey @leerob!

Is there any roadmap or similar to follow along with the development of createServerContext? Seems like it should work in Next.js at some point?

I do understand that you'd want to use regular React Context for most cases, but seems like there are valid cases for createServerContext.

unleashit Apr 21, 2023

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?

einarq Nov 14, 2023

@leerob Does those docs have a new home? That link doesn't work anymore.

MythicManiac · 2023-07-14T01:15:20Z

MythicManiac
Jul 14, 2023

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.

0 replies

ajwootto · 2024-01-18T18:44:22Z

ajwootto
Jan 18, 2024

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 cache API in a manner similar to some of the comments above. That means that all subsequent calls to the functions will just use the memoized result for the rest of this request's lifecycle.

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.

12 replies

ajwootto Jan 18, 2024

@markomitranic from my understanding the reason that next-intl needs to work that way is because it needs access to the current page's props in order to determine what locale to use. The difference with my usecase here is that I don't need anything from those props (that are only available from a page function) and everything that needs to be done per-request can be defined in a single place (the user getter above, which can do things like read from headers and cookies to determine who our user is)

unleashit Jan 18, 2024

I know they don't want to give us the full request object for various reasons

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.

ajwootto Jan 18, 2024

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).

unleashit Jan 18, 2024

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).

ajwootto Jan 19, 2024

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 headers that give you safe ways to interact with the parts of the request that are always available.

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 fetch function to cache everything by default even when not wanted.

don-esteban · 2024-01-18T21:05:28Z

don-esteban
Jan 18, 2024

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:

...As what I understand, this approach forces almost everything to be client component, child of a client component has to be client component, right?...

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 <ThemeProvider> are client components?

Yes and no. This is not true for PageComponents page.jsx. You can use Server Components inside Client Components (slot pattern) but you can't import them. You do not import page components. I'll guess this handles the framework and uses the slot pattern under the hood. But React/Next people know much better. I'm still in the beginning.

// RootLayout
export default function RootLayout({ children }: { children: React.ReactNode }) {
  return (
    <html>
      <ThemeProvider value={theme}>
          <body>{children}</body>
      </ThemeProvider>
    </html>
  );
}

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.

// A page component
"use server"; // default

import ClientComponent from "./client-component";
import ServerComponent from "./server-component";

export default async function PageComponent() {
  return (
    <ClientComponent>
      <ServerComponent />
    </ClientComponent>
  );
}

// A client component with access to Context (probably, I did not test this)
import React, { ReactElement } from 'react';

export default async function ClientComponent({children}: {children: ReactElement}) {

  const serverProp = "The client pulled this value out of context"
  
  return (
    <div>
      {React.cloneElement(children, { serverProp })}
    </div>
  );
}

// Server Component using Context
import React, { ReactElement } from 'react';

export default async function ServerComponent({serverProp}: {serverProp?: string}) {
  
  return (
    <div>
      I am a server component. I got this prop from the client: {serverProp}
    </div>
  );
}

@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.

7 replies

don-esteban Jan 18, 2024

No, I don't see the point anymore :-) Kind of tired! Tomorrow more, just this as a quick feedback.

The client gets back rendered content and (!) client side code.

// Server Component
import React from 'react';
import MyButton from './button';

export default async function ServerComponent({serverProp}: {serverProp?: string}) {
  
  return (
    <div>
      I am a server component. I got this prop from the client: {serverProp}
      <MyButton value={"I am at the client now again: " +  serverProp} />
    </div>
  );
}

// Wrap button as a client component.

"use client"

import React from 'react';

export default function MyButton({value}: {value: string}) {
  
  return (
    <button onClick={() => alert(value)}>Click me</button>
  );
}

markomitranic Jan 19, 2024

Afaik the only currently accepted solution os usage of react’s cache. This is what all the libraries that use server context, like ‘next-intl’ use.

A user above has created an utility to make this slightly easier https://www.npmjs.com/package/server-only-context

don-esteban Jan 19, 2024

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:

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?

markomitranic Jan 19, 2024

I understand the confusion, the first question was a bit too broad and asked 2 questions in one without knowing it :)

this approach forces almost everything to be client component, child of a client component has to be client component, right?

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:

Do we have any solution to implement global context but still render on server whenever possible?

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 next-intl which (unless you wish to prop-drill the locale string into every single component on both server and client) uses the context on the client, and cache on the server to share global state between components. In fact there is a npm library to make this server part easier - https://www.npmjs.com/package/server-only-context

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

ajwootto Jan 19, 2024

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 getClientContext which is then passed to a ClientsideProvider component. That way the server components can access the context data directly from the function by importing it, while the client components can receive the same shared data via their usual "context" mechanism and the useContext hook.

Can I use Server Component with a global Context? #42301

Replies: 10 comments · 36 replies

hucancode Nov 2, 2022 Author

leerob Nov 6, 2022 Maintainer

leerob Apr 20, 2023 Maintainer

Replies: 10 comments 36 replies

hucancode
Nov 2, 2022
Author

leerob
Nov 6, 2022
Maintainer

leerob
Apr 20, 2023
Maintainer