Changes to Support Meta's RSC implementation

[blittle]

TLDR: Meta's React Server Component implementation doesn't yet support context within server components. This is temporary until a new API is introduced by React. Until then, any hook or component that depends on a context within a server component has been removed. These changes have been implemented in the draft PR: Shopify/hydrogen#317

Right now Hydrogen uses a custom React Server Components (RSC) implementation. We'd like to switch to the Meta's RSC version for Hydrogen's 1.0 release. Doing so means a number of breaking changes to the framework:

App.server.jsx

All Providers have been removed from App.server.jsx within the starter template. Instead there is a new App.client.jsx component. That client component contains the context providers that are used in downstream client components. By default this is just HelmetProvider and CartProvider. If a merchant introduced a custom context provider into their App.server.jsx component, it will need to be moved to App.client.jsx.

NOTE: No downstream server component will have access to the contexts provided within App.client.jsx

ShopifyProvider

ShopifyProvider contains only the configuration data about the current storefront from shopify.config.js.
This data is static, and doesn't change after hydrogen boots. Instead of the provider, call setShopifyConfig with
the data from shopify.config.js. This needs to be done in both entry-server.jsx and entry-client.jsx:

entry-client.jsx:

import renderHydrogen from '@shopify/hydrogen/entry-client';
import {setShopifyConfig} from '@shopify/hydrogen/client';
import shopifyConfig from '../shopify.config';

setShopifyConfig(shopifyConfig);

function ClientApp({children}) {
  return children;
}

export default renderHydrogen(ClientApp);

entry-server.jsx:

import renderHydrogen from '@shopify/hydrogen/entry-server';
import {setShopifyConfig} from '@shopify/hydrogen';
import shopifyConfig from '../shopify.config';

setShopifyConfig(shopifyConfig);

import App from './App.server';

export default renderHydrogen(App, () => {
  // Custom hook
});

ReactHelmet

Provider still is used, but only in client components. The provider is setup within App.client.jsx.

ReactRouter

React Router is no longer used on the server. This means you can no longer use React Router hooks to get at param variables. Params are now passed as a prop to the top level server component. Those params have to be passed as a prop to every component that might depend on them.

export default function Product() {
    const { handle } = useParams();
    ...
}

// changes to

export default function Product({ params }) {
    const { handle } = params;
    ...
}

The client still uses React Router, though only for the Link component. I don't think that necessitates using React Router anymore at all. I propose we re-implement the Link component and remove React Router altogether.

Caching

Caching requests on the server (useQuery and useShopQuery) currently relies on context. The current cache is unique per request. That cache isolated per request by context. This has to be removed. In order to maintain the request/cache isolation, I propose that we pass a useQuery and useShopQuery prop to the root server component. Any server component that wants to fetch data would need to use those functions, instead of importing it.

export default function Product({ useQuery }) {
    const {data} = useQuery('key', async () => { ... });
}

This has the side effect of automatically making useQuery and useShopQuery only accessible in server components, because you cannot pass functions from server components to client components.

Note: the branch works right now with the context removed, but the caching is shared across all requests

ReadableStream

Official RSC needs either Node APIs or the Web Standard ReadableStream to work. Not all edge workers have implemented the ReadableStream API.

[wizardlyhel]

Some components that are using useShopQuery would need to be updated to accept theuseShopQuery as props as well (ie. Media component)

[frandiox]

Thanks for starting this @blittle !

About changes in entry-client and entry-server

I like the concept of App.client.jsx. However, what's the point of keeping this in entry-client.jsx?

function ClientApp({children}) {
  return children;
}

Couldn't this be added to App.client.jsx?
I understand the difference is that App.client.jsx runs in SSR, while entry-client does not. Is there any use case for this?

Side comment about the hook in entry-server: we are only calling it for the internal render (buffering to string), which is normally used only for bots. Do we really need it? Perhaps we should just not include it by default in our template.

Also, can't we run setShopifyConfig on the user behalf? The shopify.config.js is always at the root by convention so we could do this automatically.

React Router

+1 for removing it from the client as well if we just need the Link.

Caching

export default function Product({ useQuery }) {
   const {data} = useQuery('key', async () => { ... });
}

I like this approach more than passing request in props and then useQuery(key, fetcher, request).

As you know, we could use the server-only context we have in #390 instead. The main problems are:

• unstable_getCacheTypeFor works but is not documented. We haven't got a clear answer from React team about this yet.
• SSR context provider is possibly bugged at the React level.

Therefore, perhaps we should go with your proposed approach first until the previous issues are clarified, at least.
What do other people think?

If we eventually rely on this server-only context, perhaps using useQuery(key, fetcher, request) right now will make things easier to migrate later on.

ReadableStream

There's a feature flag that can be enabled in CFW right now to use the current implemented version of ReadableStream. With this flag, SSR and RSC won't be streamed (CFW does not support new Response(rs) yet) but at least it won't crash.

[blittle]

I like the idea of getting rid of setShopifyConfig, and moving it to be a param of renderHydrogen, thus allowing us to fail hard earlier if it isn't provided. Regarding implicitly loading the file automatically, is there value in keeping explicit? Like would devs change the config with logic? I guess the config file is already a JS file, so they could put logic (env variable) etc directly inside there. @jplhomer do you know why this was originally built to explicitly pass the config?

[blittle]

Regarding caching, the pros and cons of the approach:

Cons:

1. Awkward, you have to pass a reference to useQuery and useShopQuery wherever you want to use it.
2. Some of our build in components might now require it to be passed

Pros:

1. Automatically makes them server component only. There's no way for a client component to use them, because functions don't serialize to client components. I think this is actually really nice, I've already seen questions where people are trying to use these hooks in client components.
2. It potentially aligns with the Fix the killing of processes in monorepo hydrogen#450 (see the Accessing Shopify Data section)

[jplhomer]

I understand the difference is that App.client.jsx runs in SSR, while entry-client does not. Is there any use case for this?

I haven't found any yet. I had assumed people could use it for strictly client-only things, but even the usage there is limited. They can always create a client component and stick in in <App> for example.

Side comment about the hook in entry-server: we are only calling it for the internal render (buffering to string), which is normally used only for bots. Do we really need it? Perhaps we should just not include it by default in our template.

Nope, we haven't found an effective use for the hook option. We should remove it for now. I still see value in 3p libraries being able to hook into the render cycle to e.g. extract data (think CSS-in-JS libraries) but for now, we should remove.

do you know why this was originally built to explicitly pass shopify.config?

Nope, this was just a Hydrogen Day 1 decision. The only benefits of making it an explicit behavior are:

• ShopifyProvider can be used in other 3p frameworks like Next.js by manually injecting the config data
• ShopifyProvider can represent dynamic storefronts in a single Hydrogen app since the config can be changed based on a given request

I think setShopifyConfig is kind of an awkward API if it's ending up in user code like entry-server.jsx. If we don't end up automatically consuming the shopify.config.js file, we should investigate more ergonomic ways to inject it into Hydrogen's rendering lifecycle, like passing it as an option to renderHydrogen, so that we can swap out the mechanism later on (e.g. using Server Context when it lands) which won't require changes to user land.

Suspense Caching

The issue we're having is that we're at an awkward point where:

• React's Cache API doesn't yet work in SSR (non RSC) modes
• We're still calling regular SSR renderToReadableStream directly on the full app tree instead of consuming an existing RSC stream

Both of these will be solved soon, so we should not introduce a new change to useQuery and useShopQuery. They should continue to operate without needing a drilled-down instance of a context or request, for example.

We can keep investigating the API Routes proposal for making shop queries. I'm OK deviating from this behavior since API routes don't live in the React render lifecycle.

We should use Fran's solution for suspense caching. Even though there are flaws, it is a private API which we can swap out without causing future breaking changes.

[frandiox]

OK so let's remove the hook and that ClientApp thingy for now.
About the Shopify config, it's already passed to the plugin so we can easily provide it to internal methods using Vite. We could keep setShopifyConfig or an extra paremeter to renderHydrogen optional for those who need extra flexibility (looking at airkeys comment).

Both of these will be solved soon, so we should not introduce a new change to useQuery and useShopQuery
We should use Fran's solution for suspense caching. Even though there are flaws, it is a private API which we can swap out without causing future breaking changes.

Alright, we can get that merged soon I think.

[airkeys]

ShopifyProvider can represent dynamic storefronts in a single Hydrogen app since the config can be changed based on a given request

Our team is currently prototyping the use of Hydrogen in an app that relies on this ability to dynamically set the shopifyConfig based on request. It works elegantly on 0.8.0 and feels like a powerful tool for app devs to have this option of pulling data from multiple storefronts with Hydrogen.

We think this ability to dynamically set storefronts at 'runtime' is really valuable but we want to make sure we're not going against Hydrogen's design philosophy by doing this. Is Hydrogen meant for only one static storefront?

[blittle]

@airkeys are you saying that you are prototyping a hydrogen app where you have multiple <ShopifyProvider> components in the same hydrogen app? Are the components on the same page?

[airkeys]

We have just one <ShopifyProvider>, but we change the shopifyConfig that's passed to it based on the url param. Here's a code example adapted from our src/pages/[handle].server.jsx

export default function Page() {
  const {handle} = useParams();

  // Query rails backend for store data
  const storeData = fetchStoreData()

  // Top level hydrogen store configuration
  const config = {
    locale: 'en-us',
    storeDomain: storeData.storeUrl,
    storefrontToken: storeData.storefrontAccessToken,
    graphqlApiVersion: 'unstable',
  };

  return (
    <ShopifyProvider shopifyConfig={config}>
      <CartProvider>
        <Layout>
          <Profile />
          <div className="mt-6" />
          <ProductDetails />
        </Layout>
      </CartProvider>
    </ShopifyProvider>
  );
}

So if a user has our app installed on their store, they would be able to see their store at linkpop.com/[storeDomain]