How to incrementally hydrate Redux across page fragments during initial load?

[tigt]

I asked @markerikson about this in his Twitter DMs, and he recommended I post it here.

I’m looking for advice, concerns, caveats, needed changes, etc. from y’all’s deep Redux context, not necessarily proof-of-concept code. I found some of that in #1184, but a lot of it is specific to other technologies.

---

For an example of the kind of raw immediate pageload speed I’m targeting (and how we’re sending down chunks of HTTP streams), I wrote a post: Skeleton screens, but fast

Building off that, the gist of the output HTML stream generation would look like…

<await(headerApiCall)>
  <@then|headerData|>
    <SiteHead data=headerData /> <!-- this will be a React root -->
  </@then>
</await>

<await(pageContentApiCall)>
  <@then|pageData|>
    <PageRenderer data=pageData /> <!-- this will be a React root -->
  </@then>
</await>

<await(footerApiCall)>
  <@then|footerData|>
    <SiteFoot data=footerData /> <!-- this will be a React root -->
  </@then>
</await>

It’s simplified, but hopefully expresses my point. (This might look similar to <Suspense>, but Marko’s <await> expresses the same functionality differently. The promises for <@then> are injected from the top-level to avoid the “fetch-as-you-render” waterfall problem the React Suspense docs warn against.)

The problem: each of those newly-isolated React roots assume a monolithic Redux store is ready before they render — the SSR response was only as fast as the slowest API call. That’s what I want to avoid; once everything in headerApiCall resolves, then we should write an HTTP chunk containing the markup and enough Redux initial state to hydrate it with. The <SiteHead> should be interactive even if footerApiCall takes 10 seconds to finish.

Prior art on incremental Redux I found

Twitter Lite and High Performance React Progressive Web Apps at Scale § Batch Actions into a Single Dispatch

Necolas / Redux modules and code-splitting

Twitter Lite’s approach seems closest to what I want, but I’m not quite plugged-in enough to Redux to tell if what they’re talking about is slightly different than what I’m looking for.

How to dynamically load reducers for code splitting in a Redux application?

How to code split Redux § What about reducers?

Route-splitting reducers seems to be fairly-understood and widely-practiced by now, but are there any problems or gotchas from doing so?

I saw that RTK Query can handle streaming updates for “initial HTTP request”

How does that work?

Possibly-important details

• The eventual total transmitted JS bundle goal is 20kB, but any improvement over our current ≥52.2kB setup is welcome. For example:

  <@markerikson> FWIW, if you're only using the React-Redux hooks instead of connect, that would shave a few K off its size

• Suspense/Concurrent Mode/useMutableSource/etc. are probably “future best practice”, but this is a problem we’re solving for current customers. (We’re not even on React 17 yet 🤷)

• This is going in an A/B test, so the code doesn’t need to avoid hacks… yet.

• Our Redux code doubles as a fascinating archaeological dig. We’ve got .ts reducers next to const SIGN_IN = 'SIGN_IN', slices coexisting with /reducers/, etc.

  • Our reducers/thunks/other sundry functions implement a lot of business logic, analytics, etc. that would be a huge pain to extract.

  • It also probably contains everything you could think of. For example, a reducer that writes to localStorage to work around a SPA architecture problem.

  • We SSR, so the store is JSON-serializable.

• The streaming is called “chunked transfer-encoding” in HTTP/1.1; HTTP/2 does it differently, but the results are the same.

  • The stream must avoid another HTTP request (like how React 18 is doing the weird-not-quite JSON), instead interpolating data into the root text/html response.

  • AJAX requests might modify the still-on-server state in the middle of the HTTP request stream (unless that would be too hard to work with, in which case I’ll play ball).

• Replicating the entire store on the client is unnecessary, and arguably undesirable: it would be great to “quarantine” pieces on the server that clients don’t need.

[markerikson]

@Ephem is the main expert on Redux-related SSR that I know of. There's actually an open PR for React-Redux related to React 18 SSR support, and the last few comments of that may be relevant:

reduxjs/react-redux#1835

[Ephem]

Wow, that's an ambitious project, and a well researched post. I can't comment on everything, but I'll try to pick a few things. 😃

First of all, know that what you are getting into is a pretty big and complex problem space and something not only the React team, but other frameworks as well have spent years thinking about (Marko being early in a lot of regards). What might save you is that you are implementing this for a single specific project with known constraints as opposed to trying to solve for the general case. Also, I'd be wary of locking myself too much into a proprietary solution if that makes it significantly harder to merge with the ecosystem later, but I hear ya, having UX-problems here and now carries a lot of weight.

Redux is one big store, and a low level tool, a lot of complexity is going to be up to you to manage here. A likely problem you might run into here is if separate roots rely on the same state in the store. One root hydrates first and changes the state, now the next root and the server will have rendered with different state, causing a hydration mismatch. This might be solvable in the next major Redux version if you are on React >16.8, but even so, I think you'll probably run into other edge cases around this.

What I think you need to do is isolate the state for the different roots (at least any state that ever changes). This could still be done with a single store, but it might be easier to actually use separate stores for each root to guarantee they don't modify each other (but they could reuse parts of the initial state). I realize this probably isn't easy to do because of all that legacy code, but yeah, that's the tricky part. If you use a single store for all roots, the trick is to make each root only select parts of the store the other roots doesn't change, at least for as long as hydration of any root is still ongoing, but this is tricky to enforce, especially over time.

As for the technical details, how to actually solve this?

If you go for the separate stores route, you pass separate initialState into them when you create them. If you choose to have a single store, create a custom hydrate-action and before you do ReactDOM.hydrate(), dispatch that hydrate action with the new data for that root. How do you determine which data is new compared to already existing in the store you ask? Good question. How do you handle making sure you don't hydrate state that is already in the store, or handle the case if you still do it? Good question. This is the kind of complexity that there are no shortcuts around (at least that I know of).

A totally separate issue here is of course how to handle script loading. How do you know exactly which scripts needs to be loaded before hydrating a specific root? If you solve that, code splitting reducers and injecting them to the store before dispatching the custom hydrate action should be easy (in comparison).

A lot of this builds on the assumption that you want to start hydrating the roots as early as possible on the client, if it's the streaming html you are after but you're fine with hydrating all roots on the client after everything is done and loaded, some problems might get simpler to tackle. In that case, in Web Vitals speak, you would get a good Largest Contentful Paint, but would still have a bad First Input Delay.

Just a few random thoughts, not sure if they help. I haven't done this myself, but feel free to ask if you have any specific questions. 😄

(Note that I'm not a RTK Query user, so I'm not sure how that would handle this case, I'm speaking more generally here.)

[Ephem]

Oh, and btw, hydration mismatches aren't the end of the world, React recovers just fine from them (see this codesandbox for example), so don't let that stop you, especially from experimenting. 😃

[tigt]

Noted. I’ll be sure to run these specifics by any Redux fans we have to see if that gets their gears turning.

[tigt]

I’m researching this advice from @phryneas:

[…] you would probably not go for one store per page, but for slices that are dynamically injected when they are required/loaded for the first time. Redux is not really made for multiple stores and you won't have a lot of benefits from that.

Double-checking; this means the createSlice() API? So for each HTTP chunk, I’m picturing something like…

<script>
Object.assign(
  window.__ACCUMULATED_INITIAL_STATE__,
  JSON.parse('…serialized store fragment…')
)

reduxInstance.combineReducers(createSlice({
  name: 'site-header',
  initialState: window.__ACCUMULATED_INITIAL_STATE__,
  reducers: { …import('/reducers-for-site-header.js') }
}))
</script>

…and then extraReducers looks like the no-holds-barred extensibility point, so presumably I’m going to get real comfortable with it considering I’m about to do the definition of unforeseen library extension.

(By the way, nice taste with the convenience reexport of nanoid.)

[phryneas]

You should really not go to accumulate some initial state. It is the initial state. It will not have any effect after store is created.
As already stated: dispatch a hydration action and let your reducers respond to that.

Apart from that: not necessarily one slice per sub-page. Just use slices as you want, but use some kind of lazy injection mechanism (RTK doesn't offer one, but there are enough examples around the net).

Let your bundler figure out what needs to be sent to the client when, using import() statements.

Also, I think you are overengineering this "capturing all actions and replaying them once the reducers for them are loaded" thing. Export your actions and reducers from the same file and import() both of them. That way if the client dispatched an action, you can be sure that the according reducer is loaded at the same time.

[tigt]

Excellent, very good to know, thank you. My code sample was sketched without understanding any of the interplay, so I deeply appreciate the explanations of the consequences.

[phryneas]

I saw that RTK Query can handle streaming updates for “initial HTTP request”
How does that work?

That is another kind of streaming - making a HTTP request to an api and getting updates via websocket.

You might want to look into what https://github.com/kirill-konshin/next-redux-wrapper is doing - they allow to hydrate SSR content on a per-page basis.

[Ephem]

It's hard to say for sure without knowing more specifics (like are we talking mostly static content website, or highly dynamic webapp?), but yeah, it does sound from those constraints like React today could be a tricky fit.

Could be that in the future Server Components could be a good fit, if a large part of the page was written as such to avoid passing down JS for any part that is not actually dynamic, but that's really hard to say today, and probably wont be easy to apply to a legacy codebase to start with.

I wish I had some great advice here, rewriting everything usually isn't very feasible and is always pretty risky. Two things that helped us improve performance a lot at work was to start lazy loading reducers, and start lazy loading parts of the site below the fold. We still server render everything for bots, but for users, we only server render the top part of the page until they scroll close to the lazy content (important to use intersectionObserver for googlebot to work). This and other things let us incrementally improve performance a lot over time.

Targeting the kind of low end devices and poor network conditions you are talking about, the tradeoffs might be different though and it might take such a long time to load and render the lazy content that it ends up being a poor experience anyway.

Update: (Maybe you are already doing parts of this/have evaluated it/it wont cut it for you, just thought I'd share our journey)

[tigt]

My general sense here is that you have such highly specific requirements that a "typical" React+Redux setup isn't the right tools for your problem space, but I also have almost no experience here myself.

Yep, agreed. We started with “industry standards” in the past for what seemed like good reasons, but it appears that if we want to exceed the industry’s standard speed, we need to be more unconventional.

What do you mean by "React Suspense+SSR is weirdly gated off"?

I could have worded that better. I mean how it’s strongly recommended you use a framework implementing Server Components, or write your own, instead of treating them as a feature React itself handles for you.

[tigt]

It's hard to say for sure without knowing more specifics (like are we talking mostly static content website, or highly dynamic webapp?)

Large inventory e-commerce. Product lists and pages are mostly static with islands of user-specific state (is it in cart, applied discounts, etc.), but there’s enough products that Static Site Generators/Next.js-style static generation exhibit pathological performance in the build/deploy steps.

rewriting everything usually isn't very feasible and is always pretty risky

That was my first try; I wrote a Marko-only prototype that hits the aggressive 20kB goal with Brotli compression. We know the end state is possible, but for business concerns, a gradual migration path is important. I guess that’s why I’m asking Redux tool maintainers for forbidden Redux techniques 😅

Targeting the kind of low end devices and poor network conditions you are talking about, the tradeoffs might be different though and it might take such a long time to load and render the lazy content that it ends up being a poor experience anyway.

You hit the nail on the head. Marko’s HTML streaming and ability to automatically only send render code/hydration data for component roots with state made a lot of the performance workarounds for our current site hurt more than they help — if half the page is swathes of static <a href=…><img alt=… src=…></a>, React is buying us nothing — it’s going to only ever run those components mount/unmount lifecycles, but the user still downloads everything else for them.

[markerikson]

That's because at the moment, React absolutely does not "handle that for you" :)

Right now React is "just" a set of primitives. SSR support is (to my knowledge) mostly just ReactDOMServer.renderToString/NodeStream(), and Suspense does not yet work in SSR.

React 18 apparently adds support for Suspense in SSR scenarios, and if you read the SSR-related posts in the React 18 working group it's clear that they are working on adding more in-depth SSR support for complex use cases. Server Components are related to that but not the only part. Also, Server Components are currently at the "prototype tech demo" level and there's no full solution available, which is why Shopify's "Hydrogen" framework that uses RSCs has to build up a lot of functionality from scratch around them.

[Ephem]

if half the page is swathes of static <a href=…><img alt=… src=…></a>, React is buying us nothing — it’s going to only ever run those components mount/unmount lifecycles, but the user still downloads everything else for them.

I feel this every day. 😁 I mean, I guess what it buys is being able to render the next page by only fetching data, the JS is already cached. First visit bad vs better subsequent navigations/vists etc but yeah, not always a great tradeoff. Server Components will hopefully give us a tool where we can tweak this one to fit each specific case (low JS -> heavy markup navigations vs high JS -> low markup navigations), but it's still early and yeah, the investment will probably be high, especially implementing it yourself. 😄