Data sharing / Prop drilling

[nayaabkhan]

The Context section clarifies many use cases for sharing data among Server and Client Components.

One case also needs to be included: Passing data down from components higher up in the tree down. For example, translations fetched on a page or layout based on a URL parameter such as [locale] (see example):

import { getDictionary } from './dictionaries'

export default async function Page({ params: { lang } }) {
  const dict = await getDictionary(lang)

  return (
    <Header translations={dict.header} /> // prop drilling
      <HomePage translations={dict.homepage} />
    <Footer translations={dict.header} />
  )
}

As the dict requires lang parameter, it can only be gotten from a page or layout but not in an intermediate or leaf component, such as:

export default async function Header({ params: { lang } }) {
  const { header } = await getDictionary(lang)
  
  return ...
}

export default async function Footer({ params: { lang } }) {
  const { footer } = await getDictionary(lang)
  
  return ...
}

Neither can we use context to achieve this in a Server Component. The only possibility I see is prop drilling.

Is there a recommendation for this kind of data sharing? Preferably something other than prop drilling?

[icyJoseph]

Edit 2024

I still think that a little prop drilling isn't that bad, but I have been using React cache to share data during the SSR stage.

The main benefit of using React cache is that the memoized result of the function call is scoped to the request.

• https://react.dev/reference/react/cache#caveats

It it shown as a caveat but it actually works to our advantage.

The downside is that this data is only live during the SSR pass. Once in the client you need to find ways to revalidate it, you can think of it as being set in stone, sort of...

Here's a demo:

• https://stackblitz.com/edit/nextjs-q3dnp8?file=app%2Fpage.tsx,app%2FLocaleSwitch.tsx,app%2F[locale]%2Fpage.tsx,app%2Fserver-context.ts

The idea behind this technique boils down to this:

import 'server-only';
import { cache } from 'react';

const requestContext = cache(() => {
  return new Map<string, string>();
});

export const setRequestContext = (key: string, value: string) =>
  requestContext().set(key, value);

export const getRequestContext = (key: string) => requestContext().get(key);

First, taint the module so that it can only be imported by server side code. No use client should be able to import these.

Next, we cache a function that returns a Map. This means that, for this request:

• the first call to requestContext executes the callback and a Map is allocated
• every other call to requestContext, returns the already allocated Map

Now we set the request context value, 'locale', at page level, and we can collect it from anywhere downstream. Just like one would with a React Context Provider.

A caveat would be that if not set at page level, then we might sometimes read a non set context.

Another caveat/benefit is that pages are rendered before layouts, so you can access the data you set on the page, at the parent layout.

I tested this on local projects, firing requests with oha, and as expected the context correlates.

There's a library: https://www.npmjs.com/package/server-only-context which does the same ~ Though perhaps it is best to understand what cache is really doing, and apply that to your app.

There's a bit more of insight here as well: https://nextjs.org/docs/app/building-your-application/caching#request-memoization

Original

I am not sure if passing props one level down is prop-drilling.

The common solution is to use composition:

<A>
  <B dataForB={data} />
  <C>
      <D  {...dataforD} />
  </C>
</A>

That's always been the recommended action to avoid prop-drilling, even favoured over Context. https://www.youtube.com/watch?v=3XaXKiXtNjw - YouTube video by React Router DOM creator and maintainer Michael Jackson.

The problem is that in Server + Client components, there might be combinations where props composition is not possible. Namely because a client component cannot just have a Server Component as its children, but rather needs to first use "composition", and then be assembled at a higher level.

A grain of salt: Since this is beta technology I haven't spend much more time than playing with the documented examples, so I can't assert the above 100%

This fails:

This combination works:

However I do think that you can compose your translations so that a client component can in turn make them available downstream to its children. Again, passing props down one level, hardly qualifies as prop-drilling, so I am squinting very hard here to try and see things from your perspective.

[nayaabkhan]

To keep it concise, I chose to spell out only a few components in my example. However, if you take a typical page, it can go deep up to several levels, e.g., Header > Navigation > ... > Link. So I would need to keep passing on props at each level, even if it is not required.

I hope that makes it more clear.

Currently, this problem is solved using context. However, that is impossible in Server Components at the moment. I may be overlooking a very trivial solution.

[weilueluo]

I am having the same problem, the only way I can think of is to put the data under some /api/route.js and use fetch to abuse the de-duplicate features to share data, but I never got it to work properly

(edit: actually it is working. But as pointed out in the comments, it hurts traceability, bad in large projects)

[VenomFate-619]

can you share some code snippets for it

[weilueluo]

So in both my layout.tsx and page.tsx, I have something like:

export default async function Layout({ children, params }: Props) {
    const messages = await fetchMessages(params.locale);
    // ...rest of the code
}

Then in my fetchMessages I query the /api route like this:

export async function fetchMessages(locale: string): Promise<Messages> {
    // ...rest of the code
    const messages = await fetch(`http://localhost:3000/api/i18n/${locale}`).then(res => res.json());
    // ...rest of the code
}

Then because of the de-duplicate feature of React 18 (available in NextJs 13), only one request is sent. I do not have a minimal example, but you can see it being used here

[everythinginjs]

@weilueluo nice info thanks for sharing one thing that I am curious about is that, does dedupe feature just work for apis comming from nextjs apis ? what if I use a headless CMS which provides some apis like Strapi ? #54796

[everythinginjs]

Okay as docs says deduplication feature for fetch does not belong to next it is coming from react 18 so it works even for my scenarios

[weilueluo]

Yea that's right, sorry for the confusion, I will edit my wording

[airtonix]

nothing wrong with prop drilling my guy.

React community needs to seriously drop this toxic tutorial industry mentality about prop drilling.

[Irrelon]

in what way? that you have to type more characters? I've got news for you... that's what keyboards are for.

The number of characters you have to type is not now, and never has been the primary reason people don't like prop drilling. Suggesting it is seems like a spurious attempt to minimise the legitimate issues people have with it.

React community needs to seriously drop this toxic tutorial industry mentality about prop drilling.

You think people don't like it because they saw some tutorial telling them it was bad? It makes much more sense to assume they might have a valid and reasonable argument rather than "saw it on youtube".

Prop drilling sucks because it goes against separation of concerns. Linking usage contracts between intermediate components that don't even need those props just to satisfy the usage of them on a distant child that may or may not actually render based on application logic.

Tying your components together when they shouldn't need to know anything about each other is poor engineering form.

[ivan-kleshnin]

nothing wrong with prop drilling my guy.

Except inconvenience and worth update performance? 🤡

About performance. Prop-drilling causes the whole state -> ... -> consumer branch to reconcilate at state updates. With global state you can reconcilate only the consumer. The whole thing does not play well with the lack of signals in React and its half-assed component memoization.

[markomitranic]

The topic here is server, and there is no rerendering on the server.

Also the server props are usually things that wouldn’t change even if it were the client - like locale or magic strings.

Also server contexts do exist, so the argument isn’t viable anyway. :)

[airtonix]

Prop drilling sucks because it goes against separation of concerns. Linking usage contracts between intermediate components that don't even need those props just to satisfy the usage of them on a distant child that may or may not actually render based on application logic.

That sounds like a problem with your contract not that props are a thing.

[Irrelon]

I didn’t say props being a thing was a problem; all functions must be able to accept arguments. The problem is the contract, exactly as you have said. The contract is the description of the props that are being passed through components, linking them together, e.g. prop drilling. Essentially this boils down to a discussion about how to communicate application state to components. Moving components between different parts of the tree or different applications entirely is made burdensome and inefficient when using prop drilling, unless you just pass the entire state through every component.

[sharpsteelsoftware]

They intend for you to leverage react cache() and built-in fetch() caching with vercel data cache to refetch across components.

[davscro]

So in short I guess we are missing a way to get page params in any server component, right? I am having the same issue to understand how do this in proper way instead of passing it all the way down from Page component.

[davscro]

Maybe https://www.npmjs.com/package/server-only-context could be a solution ?

[markomitranic]

As of right now that is the only solution. The primary library next-intl actually uses the same method in prod, although they still consider it unstable

[abenhamdine]

I didn't test myself, but according to docs, the way to go is cache
see https://react.dev/reference/react/cache#take-and-share-snapshot-of-data

[davscro]

Yep, that's what server-only-context module is doing. I tested it and it works like a charm, no more props drilling 😎

[barroudjo]

The problem with React cache is that you still need to call the cached function with the same arguments, which means you have to prop drill those arguments...
You can use server-only-context to get those arguments without prop-drilling, but there's an even better way...

Disclaimer: shameless self-promotion
I found a similar pattern which requires less boilerplate, and which enables you to easily share across server components data that was asynchronously obtained: rsc-better-cache

Usage is pretty simple:

// mySharedData.ts
import { createCachedPromiseGetter } from 'rsc-better-cache';

interface MyData {
  someProp: string;
}

export const myDataPromiseGetter = createCachedPromiseGetter<MyData>();

// MyReactServerComponent.tsx (React Server Component where the data is obtained)
import { myDataPromiseGetter } from './mySharedData';

const MyReactServerComponent = async (params) => {
  const myData = await fetch(`some-url/${params.id}`);
  myDataPromiseGetter().setPromiseResolution(myData);
  // ...
}

// MyOtherReactServerComponent.tsx (React Server Component lower (or higher !) in your app tree)
import { myDataPromiseGetter } from './mySharedData';

const MyOtherReactServerComponent = async () => {
  const myData = await myDataPromiseGetter().promise;
  // ...
}

[markomitranic]

Hey @bgrayburn thanks for pitching in. I am having trouble understanding how your approach works, could you please expand on what mechanism it uses to keep a global cache?

p.s. Also perhaps this could be in the readme :D

[bgrayburn]

@markomitranic is this a mistag? Love me some next.js tho!

[markomitranic]

Haha yes I’m sorry @bgrayburn I was writing from my phone at 1AM. I meant to tag @barroudjo 😭

[barroudjo]

Haha :-D !
So it uses the same mechanism (i.e. using React's cache in a slightly different way) as https://github.com/manvalls/server-only-context (that I thought of independently, it came across this library only after making mine ! It goes to show there a real need not covered by React's cache ), only it wraps it in a promise so that it can be used not only lower in your app tree, but also at the same level or even higher. Admitedly that's a bit of a corner case, so in most cases server-only-context is a valid alternative.

[markomitranic]

@barroudjo ah ok thanks for clarifying! I have read the code last night and I saw that it used cache and wrapped it in a promise, but I didn't understand why does a Promise help - until now! Thanks :D

[markomitranic]

Hey @nayaabkhan

this question has been posed to Vercel countless times in the past year, by developers large and small. Literally the guy behind next-intl, the primary internationalization method, got radio silence. I asked them in person and got radio silence.

It can be quite frustrating.

It seems like the only way to do this as of now is using react’s cache. This is what the ecosystem decided to use “as an unstabile, tomporary solution” until something better shows up. This is what next-intl also ended up using.

https://dev.to/jdgamble555/easy-context-in-react-server-components-rsc-1mdf

[Manas-E]

It's 2024 and we're still facing such basic issues, I'm shocked to see there isn't any proper solution for such a common issue

[maxijonson]

I don't think I totally agree with this, but I also see your point about it being a backend framework, so things that would be easily accessible with just client-side React aren't the same on the server.

I don't believe avoiding prop drilling is an antipattern, but it also shouldn't be "avoided at all costs" either. "Drilling" a prop 2 or 3 components down is not the end of the world and is probably much simpler than creating a context. Especially for components that are just separated to split a large component into smaller pieces, since the individual pieces are not expected to be re-used somewhere else. But passing a prop through 20 components that don't need it, just so it can reach a leaf, doesn't seem to help component reusability, maintainability and frankly the DX of it all. It would force any components needing a page param to require all of it's parents to receive that prop too.

I think what most people (including me) are trying to achieve is to have the same ability to separate concerns in Next as you would with client side React. Currently, this can be done with traditional React contexts, at the cost of making the consumer component a client component, or using React cache, but it is still experimental, which might not be very appealing for larger projects.

Some people seem to think React devs avoid prop drilling because they were taught to. Maybe for some it's true, but in my case, I discovered React contexts back when I only used client-side React, because I was sick of drilling down props through multiple components, especially when I had to edit multiple components because one component changed or had a new child that depended on some prop. I thought to myself "there has to be a better way" and contexts were it. We just don't have "a better way" in Next currently.

That being said, you're right that it's not Next's "responsability" to give us proper "server contexts", but it's definitely something they could help out with, at least for dynamic page params, since that's their feature, not React's. I wonder if using cache would become an option for Next to help with this when it becomes stable.

[markomitranic]

Glad that you’ve read it, and thanks for the response. I actually completely agree with what you wrote.

I think you worded it very well, and I’ll update the article to contain a tiny section about this as a clarification for future readers, thanks. I’m already seeing most reads coming directly from Google, which just shows how important this topic is.

While prop drilling on its own is a good thing as it makes for simpler and pure (in a functional sense) code, there absolutely are valid cases for avoiding it. One such case, in my opinion is that there is a boundary at which prop drill devex becomes unbearable. Locale string is one such case. Without a context, you’d end up passing a locale string through every component branch that makes a fetch call to a PIM for example. For some projects that means 2 components down, for others it means hubdreds of components have to accept it as a param.

Luckily, unlike client components, we at least don’t have to deal with the issue of elongated props rerendering intermediate components.

Have you tried using the cache based server context? It works quite well in my experience so far (2 prod projects, in past 2 months)

[maxijonson]

Passing the locale is actually the exact use case right now that makes me come back to this discussion to see if people share new ideas! 😅

I haven't tried cache yet. Since it's for a company project, I wanted to wait a bit to see if other solutions came up and research more on just how "experimental" it is. Right now, I'm just going for opting into a client component. I keep seeing it come back as a solution though and no big issues so far. Since passing the locale down is pretty much the only use case we currently need it for and that's what most people using it seem to talk about, it might just be what I try when I eventually go back to work on this issue, but that won't be for at least a month as of writing this 😅

Although cache is marked as experimental, it looks like a viable solution with no issues for very simple use-cases like passing the page params. I just wish this specific use-case could be satisfied with some NextJS feature, just to make me more comfortable using it hahaha

[markomitranic]

Cache is currently used by all locale packages for Next.js for this purpose. It is also the method recommended by React mainteiners, in the PR where they deprecated createServerContext

[maxijonson]

I did not know that. Thanks for letting me know, definitely makes me more comfortable using it! 😁

[amlcodes]

my use case here is Visual Editing and Previews with a CMS (Sanity). In a page as a server component, I query for a set of information that determines if some components render. Some of those components are server components that make requests themselves. In order to use visual editing or previews with these components using a "previewDrafts" perspective with the CMS (Sanity), we use a hook to query live data. It seems like for live editable previews, the current recommendations from sanity and vercel require all components that need props from server components to be client components.

[ivan-kleshnin]

This is the server we are talking about, not the client. There are no state updates on the server.

If you load once and work with static data only... But as soon as you revalidate, refetch, etc. it goes through the whole tree of components because your awaits are in Server Components and we have to re-run them. The flow with React-Query, by contrast, would reconcile only the consuming components.

[markomitranic]

Great - but completely unimportant. And absolutely not equivalent to the issue of rerendering on the client, as some have presented it to be.

Yes It theorethically rerenders the whole page, but that is not bad at all. It is literally how every backend framework works. If it happens, it happens in miliseconds, only once, and thanks to fetch caching or react caching doesn’t need to refetch anything else, meaning the page effectively gets rebuilt from the cache. There are also boundaries that don’t get rebuilt, for example unaffected layouts or suspense children/parents, and with the advance of partial prerendering and react compiler cache the boundaries are even more granular. Basically Next is already doing a orders of magnitude less server rerendering than a traditional backend framework would.

The whole problem is mostly non-existant since its effect is equivalent (or significantly smaller) to other server frameworks - but exhagerated out of proportion, by parts of the community having certain frontend pattern expectations and trying to blindly apply them frondend framework expectations onto the server part of nextjs and mixing the two worlds.

We can actually observe the same issue when it comes to all the github discussions regarding tainting and passing props. It is 101% normal (and required) to do prop minimization and dtos between frontend and backend, but somehow the community is confused pikachu face when it comes to doing it between server and client components - expecting that they should just magically work and not care about the implications - probably because it all looks like react.

NextJS and React teams should have done a significantly better job and busting these ideas in their root and battling that sort of misinformation by educating us much more actively. For example its been almost 2 years and it is still unclear and undocumented if fetch cache lives across requests, across regions, across rebuilds etc.

[Irrelon]

@markomitranic > There is nothing wrong with prop drilling, in fact it makes perfect sense as it makes the dependencies of each intermediary component transparent instead of implicitly depending on some faraway state. We’ve known the spooky action at a distance to be an antipattern in traditional backend architecture forever now.

What a strange assertion. Are you really suggesting that prop drilling is a good pattern? Each component should have complete separation of concerns. The pattern you are advocating for makes components tied entirely to each other and the application. You couldn't move a component out of one application and into another without modifying it's prop contract. Components are supposed to be reusable. Prop drilling defeats separation of concerns.

[markomitranic]

That is where you are overlooking that different patterns exist. Nobody said contexts don't exist, they just aren't the same as they are in the client, and aren't solving the same problems. In the same way that server components look similar to client components, but are fundamentally different and have different capabilities, because they solve different problems.

As for components, they don't exclusively exist in order to be endlessly reusable. It is perfectly fine to have components that are used only once, or components that are tied to a specific context of usage, such as a parent, interface, or a context.

In fact, more explicit methods of control often result in more testable components. Yes, it is widely accepted that separation of concerns is achieved through not having components that depend on their parents magically holding a certain state that they can freely control (context/service/cache/object). Especially true in a functional environment, allowing you to control components through direct composition instead of spooky action at a distance is percicely what makes a component more reusable - if a child of your component requires A to function, then A is also your requirement. In a server setting, this would usually be made prettier through a mixture of prop drilling and dependency injection container, instead of relying on a faraway context/state. On a conceptual level, a DIC is a user-space pattern that makes prop drilling more manageable, raising the ceiling so that we don't have to reach for contexts until we have a good reason.

That is precisely why we have multiple methods of doing this - as pointed out an endless number of times. Prop drilling is perfectly fine for most use cases, and good in most use cases. You reach for a more complex method only when you have an actual need for it - for example a server context, children preloading, global scope, isometric client hydration - truly depends on what your specific need is for that specific component. Speaking in a server rendering context, most often the least expressive and most explicit method will be prop drilling and child preloading, with some contexts, only when it makes sense. Separation of concerns is exactly what happens when you make your functional components directly controllable - by moving up the aforementioned ladder, you usually carefully sacrifice control, in order to stretch that dependency, which is also fine, but should be done wisely, and not as some sort of an all-applicable best practice.

A big additional difference in the case of server side rendering is that functionality is not shared, state is not shared, only immutable data is shared, and only top down, and only once. Meaning that alongside everything written above, there is a whole class of things that would be a code smell in client components but not on the server. So my point is - don’t try to apply FE code style onto BE components. Try to re-learn what is bad and what is good, in the context of rsc, it is different than what we are used to in fe.

[ivan-kleshnin]

I can agree that RSC with prop-based data sharing fits the rest of React and can be seen as the next logical step in its evolution. It continues the same ideas of "unidirectional flow", "virtual DOM" and "let's just rerender everything" which make the React foundations. But I'm totally not convinced that this model is a perfect fit for every web app. There're content-heavy apps (~ sites) and interaction-heavy apps (~ admin panels, games, etc). Full reconcilation from the root per mutation, backend-controlled cache busting, moreover 3 versions of DOM in memory (one real + 2 virtual) are fine for content-heavy apps with occasional mutations. One issue is that you might not need a FE framework in such case (confirmed by HTMX exploding popularity), but I won't digress. React was initially positioned as "SPA view layer/library done right" but, in reality, it was never great for interaction-heavy apps. It was always too slow and too heavy. The whole existence of libraries like React-Form that explicitly violate React "best practices" bypassing React flow and primitives confirms that. I guess I'm just getting tired of React model. Have been using it since 2015, don't find it neither performant nor elegant enough for 2024. And the whole RSC hype, opt-out caching, static defaults over dynamic, BE-centric state control, pervasive NextJS influence... just made it worse for interaction-heavy SPA which I develop more often than content-heavy sites. I saw enough benchmarks to not buy into "everything is perfect about React & NextJS" cool stories, sorry 🤷‍♂️