Add Server Context deprecation warning #27424
Conversation
facebook-github-bot
added
CLA Signed
React Core Team
sebmarkbage
force-pushed
the
deprecateservercontext
branch
from
093cc1a
to
e330ce6
Compare
| // $FlowFixMe[incompatible-call] function signature doesn't reflect the symbol value | ||
| REACT_SERVER_CONTEXT_DEFAULT_VALUE_NOT_LOADED, | ||
| ); | ||
| const context: ReactServerContext<any> = { |
There was a problem hiding this comment.
why is this inlined now?
There was a problem hiding this comment.
I think that is because we don’t want to warn when this method is called which is used internally in react
There was a problem hiding this comment.
Yea and I plan on literally deleting the code soon so meh.
|
(let me know if this is better to add in an issue / discussion instead) I (partially) understand the pitfall that comes with Server Context, but I'm curious what the recommended path forward would be for "parent-child context" (can't think of a more apt name at the moment) within Server Components. For example, if I'm using something like MDX that translates markdown content to React components, I would want to know if a Here's a code reference with that pattern: https://github.com/hamlim/blog/blob/main/lib/MDXComponents.tsx#L70-L93 I suppose an alternative might be AsyncLocalStorage, and the |
Co-authored-by: Josh Story <[email protected]>
sebmarkbage
force-pushed
the
deprecateservercontext
branch
from
6c25b93
to
6b3290b
Compare
|
@hamlim The general recommendation is just to pass it manually. Most of the time it's not the end of the world. You can also pass grouped things like a general Context object that has more than one thing in it to make it easy to pass just one thing. In the MDX case, since it's all generated code anyway, an option here is to just let the generated code pass an extra "context" prop to all these components. The user doesn't have to even know. There are perhaps other new features that frameworks can provide (like maybe Next.js can give access to part of the URL like i18n) that can be specific solutions to specific problems. |
As agreed, we're removing Server Context. This was never official documented. We've found that it's not that useful in practice. Often the better options are: - Read things off the url or global scope like params or cookies. - Use the module system for global dependency injection. - Use `React.cache()` to dedupe multiple things instead of computing once and passing down. There are still legit use cases for Server Context but you have to be very careful not to pass any large data, so in generally we recommend against it anyway. Yes, prop drilling is annoying but it's not impossible for the cases this is needed. I would personally always pick it over Server Context anyway. Semantically, Server Context also blocks object deduping due to how it plays out with Server Components that can't be deduped. This is much more important feature. Since it's already in canary along with the rest of RSC, we're adding a warning for a few versions before removing completely to help migration. --------- Co-authored-by: Josh Story <[email protected]> DiffTrain build for [1ebedbe](1ebedbe)
React upstream changes: - facebook/react#27439 - facebook/react#26763 - facebook/react#27434 - facebook/react#27433 - facebook/react#27424 - facebook/react#27428 - facebook/react#27427 - facebook/react#27315 - facebook/react#27314 - facebook/react#27400 - facebook/react#27421 - facebook/react#27419 - facebook/react#27418
@sebmarkbage Server Context was very useful to not do the prop-drilling way, which is just awful. In many cases the child just need to know about a context and knows nothing about from where that context was received and the parent providing that context doesn't know about what type of child will consume the context. I also understand all the issues and communication around Server Contexts, but sad to see it leaving. @hamlim AsyncLocalStorage seems analogous for the Server Context, but it essentially works differently. With React the rendering order of components will not allow using the AsyncLocalStorage when the store is provided from within a component render. At least I don't see any way it would be possible. |
Today when we hydrate an SSR'd RSC response on the client we encounter import chunks which initiate code loading for client components. However we only start fetching these chunks after hydration has begun which is necessarily after the initial chunks for the entrypoint have loaded. React has upstream changes that need to land which will preinitialize the rendered chunks for all client components used during the SSR pass. This will cause a `<script async="" src... />` tag to be emitted in the head for each chunk we need to load during hydration which allows the browser to start fetching these resources even before the entrypoint has started to execute. Additionally the implementation for webpack and turbopack is different enough that there will be a new `react-server-dom-turbopack` package in the React repo which should be used when using Turbopack with Next. This PR also removes a number of patches to React src that proxy loading (`__next_chunk_load__`) and bundler requires (`__next_require__`) through the `globalThis` object. Now the react packages can be fully responsible for implementing chunk loading and all Next needs to do is supply the necessary information such as chunk prefix and crossOrigin attributes necessary for this loading. This information is produced as part of the client-manifest by either a Webpack plugin or Turbopack. Additionally any modifications to the chunk filename that were previously done at runtime need to be made in the manifest itself now. This means we need to encode the deployment id for skew protection and encode the filename to make it match our static path matching (and resolutions on s3) when using `[` and `]` segment characters. There are a few followup items to consider in later PRs 1. we currently bundle a node and edge version of react-server-dom-webpack/client. The node version has an implementation for busboy whereas the edge version does not. Next is currently configured to use busboy when handling a fetch action sent as multipart with a node runtime. Ideally we'd only bundle the one platform we are buliding for but some additional refactoring to support better forking is possibly required here This PR also updates react from 09285d5a7 to d900fadbf. ### React upstream changes - facebook/react#27439 - facebook/react#26763 - facebook/react#27434 - facebook/react#27433 - facebook/react#27424 - facebook/react#27428 - facebook/react#27427 - facebook/react#27315 - facebook/react#27314 - facebook/react#27400 - facebook/react#27421 - facebook/react#27419 - facebook/react#27418
We previously added a warning in #27424. This just removes it from canary/stable channels but keeps it in experimental for now.
We previously added a warning in facebook#27424. This just removes it from canary/stable channels but keeps it in experimental for now.
Because [server context has been deprecated](facebook/react#27424), we needed to find a replacement for sharing the current location. Using conditional exports, we can create a universal `useRouterLocation` hook that utilizes `AsyncLocalStorage` on the server, and normal client context in the browser. Even though the client context would also be accessible in the SSR client (we could render the context provider in `ServerRoot`), we are instead using `AsyncLocalStorage` here as well, primarily for its convenience. Although this requires placing the module containing the `AsyncLocalStorage` instance into a shared webpack layer.
Because [server context has been deprecated](facebook/react#27424), we needed to find a replacement for sharing the current location. Using conditional exports, we can create a universal `useRouterLocation` hook that utilizes `AsyncLocalStorage` on the server, and normal client context in the browser. Even though the client context would also be accessible in the SSR client (we could render the context provider in `ServerRoot`), we are instead using `AsyncLocalStorage` here as well, primarily for its convenience. Although this does require placing the module containing the `AsyncLocalStorage` instance into a shared webpack layer.
Because [server context has been deprecated](facebook/react#27424), we needed to find a replacement for sharing the current location. Using conditional exports, we can create a universal `useRouterLocation` hook that utilizes `AsyncLocalStorage` on the server, and normal client context in the browser. Even though the client context would also be accessible in the SSR client (we could render the context provider in `ServerRoot`), we are instead using `AsyncLocalStorage` here as well, primarily for its convenience. Although this does require placing the module containing the `AsyncLocalStorage` instance into a shared webpack layer.
|
For the record, in an article that shortly followed the release of RSCs, I called "Server Context" the idea of sharing data across RSCs, symmetrically to the existing React "Client Context". I still see many beginners in need for this, it's not obvious to everybody how to avoid props drilling when you have only RSCs. @karlhorky pointed a potential name clash with the name "Server Context" as being a way to pass context from RSC to client transparently. Since it's now deprecated, perhaps the "Server Context" wording could be reused again for the pattern I described? |
Server Context was never documented, and has been deprecated in #27424. This PR removes it completely, including the implementation code. Notably, `useContext` is removed from the shared subset, so importing it from a React Server environment would now should be a build error in environments that are able to enforce that.
Server Context was never documented, and has been deprecated in #27424. This PR removes it completely, including the implementation code. Notably, `useContext` is removed from the shared subset, so importing it from a React Server environment would now should be a build error in environments that are able to enforce that. DiffTrain build for [4728548](4728548)
As agreed, we're removing Server Context. This was never official documented. We've found that it's not that useful in practice. Often the better options are: - Read things off the url or global scope like params or cookies. - Use the module system for global dependency injection. - Use `React.cache()` to dedupe multiple things instead of computing once and passing down. There are still legit use cases for Server Context but you have to be very careful not to pass any large data, so in generally we recommend against it anyway. Yes, prop drilling is annoying but it's not impossible for the cases this is needed. I would personally always pick it over Server Context anyway. Semantically, Server Context also blocks object deduping due to how it plays out with Server Components that can't be deduped. This is much more important feature. Since it's already in canary along with the rest of RSC, we're adding a warning for a few versions before removing completely to help migration. --------- Co-authored-by: Josh Story <[email protected]>
We previously added a warning in facebook#27424. This just removes it from canary/stable channels but keeps it in experimental for now.
Server Context was never documented, and has been deprecated in facebook#27424. This PR removes it completely, including the implementation code. Notably, `useContext` is removed from the shared subset, so importing it from a React Server environment would now should be a build error in environments that are able to enforce that.
As agreed, we're removing Server Context. This was never official documented. We've found that it's not that useful in practice. Often the better options are: - Read things off the url or global scope like params or cookies. - Use the module system for global dependency injection. - Use `React.cache()` to dedupe multiple things instead of computing once and passing down. There are still legit use cases for Server Context but you have to be very careful not to pass any large data, so in generally we recommend against it anyway. Yes, prop drilling is annoying but it's not impossible for the cases this is needed. I would personally always pick it over Server Context anyway. Semantically, Server Context also blocks object deduping due to how it plays out with Server Components that can't be deduped. This is much more important feature. Since it's already in canary along with the rest of RSC, we're adding a warning for a few versions before removing completely to help migration. --------- Co-authored-by: Josh Story <[email protected]> DiffTrain build for commit 1ebedbe.
As agreed, we're removing Server Context. This was never official documented.
We've found that it's not that useful in practice. Often the better options are:
React.cache()to dedupe multiple things instead of computing once and passing down.There are still legit use cases for Server Context but you have to be very careful not to pass any large data, so in generally we recommend against it anyway.
Yes, prop drilling is annoying but it's not impossible for the cases this is needed. I would personally always pick it over Server Context anyway.
Semantically, Server Context also blocks object deduping due to how it plays out with Server Components that can't be deduped. This is much more important feature.
Since it's already in canary along with the rest of RSC, we're adding a warning for a few versions before removing completely to help migration.