[atoko]

I wonder if the omission of React Context in this example is intentional. Do you think Context is compatible with suspense? In the sense that posts is being passed to components as props three times over.

Is it because each component is expected to abstract over async, relying on the promise state?

[danabramov]

Not sure what you mean — we’re just reading some files from the disk and passing that down. It doesn’t need Suspense because everything is static (so no loading indicators are needed). If this was dynamic then I’d probably still not add a loading indicator because you expect a blog index to “pop in” with the rest of the page rather than behind a spinner.

[atoko]

Thanks!

More concisely: it’s not always the case that prop drilling is possible within a component hierarchy. In a more involved application you store this object in context.

Is what you are describing compatible with this pattern? How does this inform the design of RSCs and as a developer, how can I expect this to affect me?

[danabramov]

This depends on how you need to use this object.

One way would be to put it into Client context near the top, then it will be available in Client context below. So if it’s just for the Client stuff, your existing approach works.

For data fetching, a more common approach is not to do any “passing down” at all. Instead, have components that need that data below read that data independently. Slap React.cache around the function that gets the data so that all calls are reused across a single request. Then the first call kicks it off and the other calls will wait for the same Promise under the hood. And you can kick off preloading somewhere up above in the tree if you want to eagerly begin.

That should cover most cases.