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

• The ClientProxy is basically wrapping components in ForwardRefs. The only reason to do this is so that the whole thing evaluates to typeof 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 the attemptResolveElement logic a bit.
• This does not use any manifest or "bundler config" because it relies on Vite's glob imports (a manifest could be added later to reveal dependencies earlier). These imports are injected around the __INJECTED_CLIENT_IMPORTERS__ object.

Apart from implementation details that can be fixed or improved, would this be a valid approach in your opinion? Or would it be valid without the SSR piece (i.e. only RSC without merging module references and components)? Any other ideas that work with the constraints mentioned above?

It would be interesting to generate the RSC flight response at the same time of doing SSR since tree nodes are both components and module references. However, I don't think there's any way to hook into that process right now.

There's a demo project using this implementation here (only RSC, not SSR): GitHub source | Stackblitz live demo