Official RSC exploration

[frandiox]

Description

Related #249

Background

Today, Hydrogen uses a reverse-engineered version of server components which supports context and SSR in Hydrogen.

Specifically, Hydrogen wraps client components in logic which forks their output based on whether they're being rendered in a SSR or a RSC context (using Providers to know if the current rendering is RSC or not).

When responding to a RSC request, the client component wrappers render a <span> containing data attributes about the client component and the passed props. Hydrogen renders the entire tree to HTML and then re-parses it using a third-party library, generating the NDJSON "wire" syntax as the output. This is really inefficient, fragile and cannot be streamed.

Our goal is to remove this code as quickly as we can properly support the official React Server implementation in Hydrogen apps.

Incompatibilities with official React 18 experimental

As far as I understand, React 18 experimental supports the following features in isolation:

• SSR streaming: by loading client components normally in the server, it can do SSR and stream the progress.
• RSC: by loading a "component descriptor" (i.e. plain object containing filepath and name of the component) instead of the actual client component in the server, it can generate the wire/flight syntax for RSC. Replacing actual client components with their corresponding descriptors is done via Node registers/loaders when passing --conditions react-server to the Node runtime.

It is not obvious to me that both features can be combined right now, because based on the public demos you either load actual client components or only the descriptors in the server.

However, Hydrogen needs both, components and descriptors, at the same time in order to do SSR + RSC in the same process. This could be achieved by importing 2 different server bundles but this seems problematic and would slow down the development server.
On top of that, Hydrogen is supposed to run on Oxygen/workers, where nothing like --conditions can be passed to the runtime.
And of course, Hydrogen uses Vite instead of Webpack, which is the only tool that has official support at the moment.

New approach

Instead of Node --conditions, this PR uses a hook in Vite to generate the descriptor. This descriptor is "merged" with the actual component in a proxy and will behave differently depending on the renderer (we don't need Provider/Context anymore).

When the app tree is passed to React SSR renderer, the proxied client components will be returned as normal components -- they are actually wrapped in React forward refs due to some constraints but the point is that they are rendered normally as real components.
However, when the app tree is passed to React RSC renderer, and thanks to a customizable isModuleReference hook, the proxied client components will behave as RSC descriptor instead, outputting the correct wire/flight syntax.

Apart from that, since we are still using Vite's dynamic imports from the client, we don't need a manifest to generate or interpret the RSC payload. We just pass the module ID to Vite's helper in the browser and it figures out the way to download it.

The tricky part in all of this is merging actual components with their descriptors so they work for both flows in the same process. Also, the way this PR accesses React flight logic is by importing directly from react-server and react-client packages, which are not published to NPM at the moment (they are linked to a local version of React).

Unknowns

• Does this approach align with what React team has in mind, or will it break due to any change upstream?
• Are react-server and react-client going to be published to NPM, or do we need to make a PR to React repo with a Vite plugin instead?
• How does this work with hydrateRoot? Related Library Upgrade Guide: <script> (e.g. SSR frameworks) reactwg/react-18#114
• How do we generate the RSC wire/flight payload and SSR at the same time? Right now we do SSR first and then RSC after that, which is obviously slower because it traverses the app tree twice (although fetch sub-requests should be cached and reused). We can make some tricks to preload RSC components in the frontend during SSR streaming but we still need to wait for the final RSC wire/flight payload for the actual hydration.

Update

• react-server and react-client packages are not going to be published to NPM. We have now submitted a Vite plugin in React repo. A compiled version of this plugin has been added to this PR in vendor/react-dom-server-vite.
• Combining SSR and RSC responses can be done following this strategy (already merged in this PR). Another strategy would be generating RSC first, consume that response within the server, and pass the result to SSR (but this is bugged in React Bug: [Flight] renderToReadableStream with Suspense never resolves in some circumstances facebook/react#23113)

Setup

1. Run yarn dev-lib in Hydrogen root
2. Run yarn dev-server in Hydrogen root when the lib finishes

---

Before submitting the PR, please make sure you do the following:

• Add your change under the Unreleased heading in the package's CHANGELOG.md
• Read the Contributing Guidelines
• Provide a description in this PR that addresses what the PR is solving, or reference the issue that it solves (e.g. fixes #123)
• Update docs in this repository for your change, if needed

[wizardlyhel]

Nice to know that we can get unstable_getCacheForType working here. I had a lot of trouble to get by that --condition react-server flag with the webpack version.

But since we are looking for a Vite implementation package that will include react-server stuff, do we still need to put this functionality behind some kinda flag? (Asking without in-depth knowledge around Vite plugin ecosystem)

[frandiox]

If this approach or something similar is "approved" by the React team, then we won't need any flag since there's only 1 environment running. I'm not sure if they will like the fact that we "merge" components and modules in the same environment, though 😬

[wizardlyhel]

That is what react-server-dom-webpack did. It includes codes from react-server .. and I believe that is how React wants to move forward with any framework integration with react-server.

We can double check that in the working group.

[frandiox]

@wizardlyhel Yes, they use Rollup to combine different files from webpack and react-server. However, they also generate a "standalone" version of react-server that can just be imported (and pass all the webpack/vite overrides as parameters). This is what I'm using in this PR.
However, when making a PR to React repo, I'll change it to the other approach using Rollup (they said they are not going to publish react-server and react-client packages).

---

What I meant with "merge" components is that in this PR, a client component is a proxy that returns different stuff depending on the current renderer (ssr / rsc) but it works with just 1 bundle and in 1 process. What I've seen in the demos and diagrams from the React team, however, is that you need either 2 bundles or at least different 2 Node environments.

[wizardlyhel]

I notice this filepath is now the full filesystem path like "id":"/Users/ ... /Shopify/hydrogen/packages/dev/src/RSCTest/C1.client.jsx" Should this be relative path to the serving root?

[frandiox]

Ideally yes but this is also connected to Vite's dynamic imports so we need to change that first (and might be troublesome).

[wizardlyhel]

Overall - I'm excited that this PR took out a lot of our custom logics.

With regards to context/provider, this is work-in-progress of us removing packages that heavily depends on context like react-query and react-helmet and provide a RSC compatible replacement. We will also need that unimplemented Server Context which we think that will take care of the server state provider.

[wizardlyhel]

Tried to load this in worker and it didn't work. The RSC didn't even generate a serialized response.

If you want to load the dev project in a worker, just do the following:

1. Replace dev/worker.js with the following

  // import handleEvent from '@shopify/hydrogen/worker';
// import entrypoint from './src/entry-server.jsx';
// // eslint-disable-next-line node/no-missing-import
// import indexHtml from './dist/client/index.html?raw';

// addEventListener('fetch', (event) => {
//   try {
//     event.respondWith(
//       handleEvent(event, {
//         entrypoint,
//         indexTemplate: indexHtml,
//         cache: caches.default,
//         context: event,
//       }),
//     );
//   } catch (error) {
//     event.respondWith(
//       new Response(error.message || error.toString(), {
//         status: 500,
//       }),
//     );
//   }
// });

import handleEvent from '@shopify/hydrogen/worker';
import entrypoint from './src/entry-server.jsx';
// eslint-disable-next-line node/no-missing-import
import indexHtml from './dist/client/index.html?raw';
import {getAssetFromKV} from '@cloudflare/kv-asset-handler';

async function assetHandler(event, url) {
  const response = await getAssetFromKV(event, {});

  if (response.status < 400) {
    const filename = url.pathname.split('/').pop();

    const maxAge =
      filename.split('.').length > 2
        ? 31536000 // hashed asset, will never be updated
        : 86400; // favico and other public assets

    response.headers.append('cache-control', `public, max-age=${maxAge}`);
  }

  return response;
}

addEventListener('fetch', (event) => {
  try {
    event.respondWith(
      handleEvent(event, {
        entrypoint,
        indexTemplate: indexHtml,
        assetHandler,
        cache: caches.default,
        context: {
          waitUntil: event.waitUntil ? (p) => event.waitUntil(p) : undefined,
        },
      }),
    );
  } catch (error) {
    event.respondWith(
      new Response(error.message || error.toString(), {
        status: 500,
      }),
    );
  }
});

2. Add "dev-worker": "yarn build && npx miniflare dist/worker/worker.js -s dist/client", in dev/package.json scripts
3. Add "dev-worker": "cross-env LOCAL_DEV=true VITE_INSPECT=1 yarn workspace dev dev-worker", in <root>/package.json
4. Run yarn dev-worker in root folder

[frandiox]

@wizardlyhel Ah yes, this PR is not prepared for workers yet due to lack of ReadableStream. As you know, in the previous approach we were buffering the RSC response and returning plain text instead of streaming in workers. However, I haven't implemented that buffering here since this is still blocked by other stuff and the ReadableStream should be available soon.

If you are curious, I think the RSC request in workers is dying either here or here.

[blittle]

This PR is 🤯. Maybe I'll schedule a time where @frandiox you could could walk me through it?

[wizardlyhel]

Right - I keep forgetting about the missing ReadableStream support in workers.

[frandiox]

@blittle Sure! Tuesday/Wednesday morning JST (your afternoon/evening 1 day before) works for me 👍

[frandiox]

@Aslemammad @blittle it's finally greeeeeen 🟢 💚 🍏 📗

[Aslemammad]

@frandiox Thank you for the opportunity; that's the least I could do!

[jplhomer]

Update: I added back ShopifyProvider and made it easy to pass shopifyConfig to renderHydrogen on both entry-client and entry-server.

I also removed hook etc from those entrypoints, since they aren't even functional.

This unlocks:

• The ability to keep ShopifyProvider for non-RSC usage (and on the client)
• The ability for us to change our local caching mechanism for shopifyConfig without it being a breaking change

I think it makes sense for renderHydrogen to take care of wrapping the app in <ShopifyProvider> 👍

I feel good about merging this into an experimental branch.