-
Notifications
You must be signed in to change notification settings - Fork 47.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Vite plugin for React Server Components #22952
Conversation
Hi @frandiox! Thank you for your pull request and welcome to our community. Action RequiredIn order to merge any pull request (code, docs, etc.), we require contributors to sign our Contributor License Agreement, and we don't seem to have one on file for you. ProcessIn order for us to review and merge your suggested changes, please sign at https://code.facebook.com/cla. If you are contributing on behalf of someone else (eg your employer), the individual CLA may not be sufficient and your employer may need to sign the corporate CLA. Once the CLA is signed, our tooling will perform checks and validations. Afterwards, the pull request will be tagged with If you have received this in error or have any questions, please contact us at cla@fb.com. Thanks! |
Thank you for signing our Contributor License Agreement. We can now accept your code for this (and any) Meta Open Source project. Thanks! |
What do you think it'd take to get ServerContext working, I tested |
@natew I just updated this plugin with the latest changes in upstream. Not sure if it will fix your issues, though, but you can give it a try. Other than that, I think there's not much to do in this plugin about Server Context 🤔 |
Closing this since it's outdated and there's a new approach following the latest conventions in #26926 |
Summary
Hi! This PR implements a Vite plugin for React Server Components. This is the approach we are currently exploring at
@shopify/hydrogen
and is extracted from here. Hydrogen is right now using a custom implementation of RSC but we would like to switch to the official implementation as soon as possible and make it work with SSR. This PR is meant to serve as a discussion to see what would be the best approach and some trade-offs.Assumptions and constraints
As far as I understand, React 18 experimental supports server components by importing a "module reference" instead of actual client components in a Node process. This is done by using Node's native
--conditions
and registers/loaders. However, in order to do SSR we need the "real" client components in the process, not these module references. Therefore, it sounds like these two features are right now mutually exclusive unless we create 2 bundles or 2 different Node environments.On the other hand, Vite typically runs on only 1 process and its philosophy is basically no-bundles in development to speed things up. Plus, the main build target for Hydrogen is Oxygen and Cloudflare Workers, which can't be run as 2 processes and don't have Node's native
--conditions
or registers.Proposed approach
Instead of relying on Node flags or registers, the Vite plugin in this PR is wrapping every client component in a proxy that merges the component itself with its module reference in the same object. The React SSR renderer will treat this resulting object as a normal component whereas the RSC renderer will use it as a module reference. This way, it can run RSC and SSR in the same process without requiring multiple bundles or Node flags.
Implementation details and clarifications
TheClientProxy
is basically wrapping components in ForwardRefs. The only reason to do this is so that the whole thing evaluates totypeof component === 'object'
(instead of'function'
) in order to reach this line in the RSC renderer. This could be simplified if we are willing to change theattemptResolveElement
logic a bit. Also, this proxy could be removed if we only want to support RSC=>SSR (consuming RSC response in the server, then triggering SSR with that). It is needed, however, if we want to support running pure SSR without a prior RSC pass.__INJECTED_CLIENT_IMPORTERS__
object. Vite automatically adds a list of sub-dependencies to each of the client components so, when downloading a component during hydration, it gets all the sub-dependencies together to avoid waterfall requests.Apart from implementation details that can be fixed or improved, would this be a valid approach in your opinion? Any other ideas that work with the constraints mentioned above?
There's a demo project using this implementation here (only RSC, not SSR): GitHub source | Stackblitz live demo