RFC: Partial Hydration

[Khaledgarbaya]

Summary

We’re happy to announce Partial Hydration in Gatsby 5. You gain the ability to mark specific parts of your site/application as “interactive,” while the rest of your site is static by default. See the design section for more information on how this works.

Partial Hydration is one of the major features of Gatsby 5. See its release notes to learn more.

Getting started

Warning
This is a Beta, we strongly recommend to try Partial Hydration on a development branch of your site (no YOLO’s yet, please!).

Using the Partial Hydration Starter

Clone the existing starter gatsby-partial-hydration-starter

cd gatsby-partial-hydration-starter
npm install --legacy-peer-deps
npm run build
npm run serve

Using the Partial Hydration with an existing project

You can get started by enabling the PARTIAL_HYDRATION flag in gatsby-config together with installing gatsby@next, react@experimental, and react-dom@experimental. Now to mark a component as interactive, at the top of the file, add the string with the quotes "use client" and you’ll see the magic happen.

// gatsby-config.js
module.exports = {
  flags: {
    PARTIAL_HYDRATION: true
  }
}

npm install –-save-exact --legacy-peer-deps gatsby@next react@experimental react-dom@experimental

Using an online IDE

• Codesandbox
• Stackblitz

Motivation

Most Gatsby sites are content-based and require only a few sections to be interactive. However, to ensure click events, effects, and state changes work correctly, we must download the JavaScript that handles these events. Unfortunately, this behavior can lead to a lot of unused JavaScript being downloaded, making your website slower and more expensive.

We want to give you the best of both worlds with Partial Hydration. Using React’s great DX/UX, we can produce smaller JavaScript bundles and increased Lighthouse scores!

Here's a short demo to show why it's so cool!

Known issues (during Beta)

• Only works with gatsby build/gatsby serve, and not gatsby develop
• Bundling of JavaScript is not fully optimized for Partial Hydration, you might still see large JavaScript files be downloaded
• Error handling is missing during static rendering

Design

Partial hydration is powered by “React Server Components”. We implemented the latest draft. Therefore, the implementation of Partial Hydration might slightly change throughout the beta.

When you enable partial hydration, we start generating server components output starting from the page level. All top level components that have interactivity need to be marked as interactive by applying "use client".

"use client"

export function MyInteractiveComponent() {
  const [myState, setState] = useState(null);

  useEffect(() => { setTimeout(() => setState(‘interactive’) }, 3000)

  return <div>{myState}</div>
}

Interactive components

Any component that contains “useEffect”, “useState”, “createContext” or event handlers are considered interactive components. Also class components are not compatible with server components and should be marked as interactive as well.

How do I know it’s working?

When running Gatsby build you’ll see a couple of new activities:

...
success Building Partial Hydration renderer - 1.885s
...
success Building Partial HTML for pages - 0.113s - 6/6 52.96/s
…

Run gatsby serve or deploy to Gatsby Cloud to see the results working. You should see Gatsby fetching a page-data-rsc.json file and no page component javascript file.

How can you help?

• What do you think of the API?
• How difficult is it to convert your application?
• Do you think you will convert your application to use Partial Hydration?
• Are there any concerns about the implementation?
• Join the partial-hydration Discord channel

[SachaG]

This is so cool! Very excited to check it out. Some early thoughts before trying this out:

• I will need to rethink how I load my data to take advantage of this. For example, a lot of the data I need is passed through components using the page context, but doing that will automatically bundle that data on the client as well, which is unnecessary if it's only used by non-hydrated components. Maybe new APIs are needed, like a serverContext?
• If I understand correctly enabling partial hydration will break all interactive components until you manually add "client export" to every single one of them? Maybe it would make more sense to do it the other way around, where you have to opt-in for components that you don't want hydrated, just to avoid breaking existing apps? Or else maybe give users the choice?
• Adding a magic string at the top of a file feels weird, I've never seen this kind of API before. It's also something that people could easily get wrong and won't throw an error. But that seems like a decision made at the React level, so probably not something Gatsby can or should change.

[LekoArts]

(This is just my understanding of things)

Maybe it would make more sense to do it the other way around, where you have to opt-in for components that you don't want hydrated, just to avoid breaking existing apps? Or else maybe give users the choice?

From our experience the default of "server" should serve most people better than the other way around. It'll also allow us to make Gatsby more lightweight by default, people don't have to think about it. I agree to what Dan says in the RFC:

When you learn about it, you’ll probably initially try to use “client” transitively and it will work. But at some point you’ll realize it’s not required. Since it’s strictly less work to not write it, people will naturally learn to only annotate actual client roots.
Is there some way to warn (eg during build) for unnecessary client opt-ins? Is this even a thing? Or do you want to sometimes annotate a client root even if it’s not actually used as a client root from any server file right now? Similarly, should there be any nudge to remove the annotation from non-client-poisoned files that don’t use any client features?

Adding a magic string at the top of a file feels weird, I've never seen this kind of API before.

Because most likely your build tooling always handled one prominent case for you: use strict mode
It's like other directives. See Sebastian's comment:

I looked into a number of minifiers (closure compiler, uglify, swc) and it looks like they tend to leave string statements (directives) alone on the module scope even if they're not the string "use strict" (there's also "use asm", "hide source" etc. in other proposals).
This makes it better for publishing to npm using the string instead of a comment where as a comment would be removed by a minifier when you export it and then it would lose its ability to be exported to the server.

[gaearon]

If I understand correctly enabling partial hydration will break all interactive components until you manually add "client export" to every single one of them?

It shouldn’t be every single one of them. Only the ones that you import from the “server” world. Client components imported only from other client components don’t need the directive.

[angeloashmore]

Hi team! Partial hydration sounds great! I'm the author and maintainer of Prismic's Gatsby plugins and will be testing them out with Gatsby 5.

The source plugin (gatsby-source-prismic) works without issue, but the preview plugin (gatsby-plugin-prismic-previews) seems to break website builds that use partial hydration. The preview plugin uses higher order components to inject runtime code into components. It seems using HOCs breaks page builds.

The following errors appears when running gatsby build:

# ...

success Rewriting compilation hashes - 0.052s
success Building static HTML for pages - 3.357s - 1/1 0.30/s
failed Building partial HTML for pages - 0.073s

 ERROR #80000

Building partial HTML failed for path "/"

This can happen if interactive elements like "useEffect", "useState", "createContext" or event handlers
are used in a component without declaring the "client export" directive at the top of the file.

Consider adding "client export" to the top of your file if your component is interactive,
otherwise refactor your component so it can be statically rendered with React Server Components (RSC).



  Error: Unsupported server component type: {...}

  - react-server-dom-webpack-writer.node.production.min.server.js:34 P
    [gatsby-5-hoc-partial-hydration]/[react-server-dom-webpack]/cjs/react-server-dom-webpack-writer.node.production.min.server.js:34:92

  - react-server-dom-webpack-writer.node.production.min.server.js:38 ua
    [gatsby-5-hoc-partial-hydration]/[react-server-dom-webpack]/cjs/react-server-dom-webpack-writer.node.production.min.server.js:38:157

  - react-server-dom-webpack-writer.node.production.min.server.js:32 Array.toJSON
    [gatsby-5-hoc-partial-hydration]/[react-server-dom-webpack]/cjs/react-server-dom-webpack-writer.node.production.min.server.js:32:408

  - stringify

  - react-server-dom-webpack-writer.node.production.min.server.js:44 za
    [gatsby-5-hoc-partial-hydration]/[react-server-dom-webpack]/cjs/react-server-dom-webpack-writer.node.production.min.server.js:44:301

  - react-server-dom-webpack-writer.node.production.min.server.js:47 Immediate._onImmediate
    [gatsby-5-hoc-partial-hydration]/[react-server-dom-webpack]/cjs/react-server-dom-webpack-writer.node.production.min.server.js:47:95

  - timers:471 processImmediate
    node:internal/timers:471:21

I created a minimal reproduction including a page using a HOC (it does nothing except forward the component) and "client export".

https://github.com/angeloashmore/gatsby-5-partial-hydration-hoc-issue/

git clone https://github.com/angeloashmore/gatsby-5-partial-hydration-hoc-issue
cd gatsby-5-partial-hydration-hoc-issue
npm install --legacy-peer-deps
npm run build

Are there special steps involved to get HOCs working with partial hydration?

[LekoArts]

Mhh, I don't understand why it doesn't work 🤷 It should work (tm)

[angeloashmore]

@LekoArts Should I open an issue? I wasn’t sure if it should be noted here or in Issues since it is Gatsby 5-specific.

[LekoArts]

Anything not in latest and running as an experiment we discuss in their respective GitHub discussions :) I'm not sure if I get to it this week to debug this, if you (or anyone else) have time, I'd probably start with adding debugging statements to the React source code I linked above.

[angeloashmore]

👍

[axe312ger]

Any chance to get the path to the actual component that fails? Got the same error and wonder what it is.

[axe312ger]

Any idea what is wrong?

> gatsby develop


 ERROR #11901  COMPILATION

Failed to compile Gatsby files (@parcel/optimizer-terser):

You must provide the URL of lib/mappings.wasm by calling SourceMapConsumer.initialize({ 'lib/mappings.wasm': ... }) before using SourceMapConsumer.

[tyhopp]

Only works with gatsby build/gatsby serve, and not gatsby develop

This is one of the things we're working on during the alpha

[bre7]

Any idea what is wrong?

> gatsby develop


 ERROR #11901  COMPILATION

Failed to compile Gatsby files (@parcel/optimizer-terser):

You must provide the URL of lib/mappings.wasm by calling SourceMapConsumer.initialize({ 'lib/mappings.wasm': ... }) before using SourceMapConsumer.

Same as #35607 ?

[verystack]

The current implementation of Partial Hydration is going to make it difficult to use CSS-in-JS isn't it? I'm trying it now on one of my client's projects that is styled with Emotion and it's bug city. Astro's isolated bundling works far better - even if it doesn't support CSS-in-JS either yet officially.

As I said in their RFCs as well (withastro/roadmap#202) - one of the key promises of partial hydration is non-client rendering of CSS-in-JS components for the multitude of instances where an org can't/won't/shouldn't use other styling options.

Static CSS/Tailwind/etc companies saving a few KB and boosting an already good PSI score is nothing compared to the big TBT improvements that support for CSS-in-JS would be able to deliver for other companies. Without this RFC is DOA.

[LekoArts]

This is completely in the hands of the CSS-in-JS solution you're using, see reactwg/react-18#110 or by @gaearon in reactjs/rfcs#188 (comment):

But yeah, this is a follow-up use case, similar to how we'll need to figure out what CSS solutions should do.

I don't get that sentence:

Astro's isolated bundling works far better - even if it doesn't support CSS-in-JS either yet officially

How can it be better if it doesn't work, too? I think your feedback should be directed to React directly as this needs to be handled upstream and can't be handled by us.

[dan-mba]

Since Partial Hydration is using React Server Components, does that mean it is SSR only?

Or am I not understanding Server Components correctly and they will work with static sites.

[LekoArts]

No, we'll use React Server Components for the SSG portion of Gatsby (as a starter). This is how Partial Hydration will work for us.

[LekoArts]

A new spec is out (https://github.com/reactjs/rfcs/blob/main/text/0227-server-module-conventions.md) and we've updated our implementation.

You have to use "use client" now!

[ZeldOcarina]

Hi!
Since for some reason I don't understand gatsby serve is not suitable for production use, make sure to document a way to use this feature in production for the open source community too otherwise we'll be forced into using Gatsby Cloud which is not a fair marketing practice imo.

[LekoArts]

It‘s a 100% OSS feature, it‘ll work everywhere as it just happens during gatsby build

[ZeldOcarina]

But you wrote earlier you need to be behind gatsby serve or Gatsby Cloud, would it work if I serve the static folder with NGINX? Thanks for the clarification.

[KyleAMathews]

Those are just two ways to view the built site. All the work to setup partial hydration happens at build time and in the browser so how you serve the site doesn't matter.

[Khaledgarbaya]

@ZeldOcarina, the gatsby serve is for you to test your site locally; you need a server to preview your site locally. Once your website is built, you can host it anywhere. No one is forced to use anything here, and there is no lousy marketing practice.

[ZeldOcarina]

Amazing thanks a lot for the clarification! :)
Sorry if I sounded a bit harsh, I've had troubles in the past using SSR and I've had to build my own backend due to not be able to use Gatsby functions as gatsby serve doesn't work on production.
I've built something I think is interesting in Gatsby and my agency (it's listed, Monarchy Media) has now a lot of Gatsby sites and many more to come.
I think a small side bar with you guys might be mutually beneficial.
Maybe this is a bit OT. Sorry for that.

[sensedrive]

Clone the existing starter gatsby-partial-hydration-starter

First of all! Thank you for this great feature! I`ve been playing around with this this morning and I would like to give some comments on it:

• @SachaG mentioned:

  If I understand correctly enabling partial hydration will break all interactive components until you manually add "client export" to every single one of them? Maybe it would make more sense to do it the other way around, where you have to opt-in for components that you don't want hydrated, just to avoid breaking existing apps? Or else maybe give users the choice?

  I agree with him to some extent. With the current approach it is not possible to upgrade any (yes, any) of my applications to Gatsby V5. Especially our layouts use a lot of "React" functionality, esspecially contexts. For example, we use a I18Context Provider at the highest level of our pages, which will be feeded with some basic I18n information.

• While playing around, I noticed that the following code generates an error on build. It seems that "use client" in the comment is responsible for this. When I remove "use client" from the comment, the build works without errors.

/**
 * To mark a component as client side, you add the "use client" directive.
 */
import React from "react"

export function Demo() {
    return (
        <div>
            <div>{1}</div>
            <div>{2}</div>
            <div>{3}</div>
        </div>
    )
}

I get this error

• I was a little confused after watching this video https://www.youtube.com/watch?v=lgc6SrINnSc. Without knowing this threat, it hides very important information about what will change from Gatsby V4 to V5. Also the section with the "network tab" and chunks feels like it was thrown into the void.

• I may did not read carefully, but will it be possible to use a non "use client" component inside a "use client" component? Especially our latest Childnodes are often using React libraries to modify the output (date-fns, html-react-parser (from wysiwyg output), react-player).

Thank you very much!

[LekoArts]

With the current approach it is not possible to upgrade any (yes, any) of my applications to Gatsby V5.

Partial Hydration is still in Beta, thus with Gatsby 5 it'll still be behind a flag and disabled by default. So the currently existing limitations of React server components won't block the upgrade to Gatsby 5.

When I remove "use client" from the comment, the build works without errors.

We fixed this bug, thanks for reporting that!

I was a little confused after watching this video

We'll have a new video for the Gatsby 5 release which will hopefully be more clear!

I may did not read carefully, but will it be possible to use a non "use client" component inside a "use client" component?

We'll have docs for this, preview here: https://github.com/gatsbyjs/gatsby/blob/d3b38468d54bd57e625954af29f3101df5388ce5/docs/docs/how-to/performance/partial-hydration.md#can-i-import-server-components-into-client-components

[iankduffy]

I seem to have an issue where I can't pull in functions from a separate JS file ie utility functions and use them on client components, in the network tab I get 404 files for /undefined-undefined.js the code works if I put the functions in the react component but this means duplicated functions, any idea if this is something that will be changed?

[LekoArts]

This should be working, yes. Quite possible that it's a bug on our side right now. Can you share code examples and/or a repository? Thanks!

[wojciechbator]

I have a problem using this along with gatsby-plugin-offline. Without the plugin, website builds correctly and partial hydration seems to be applied, judging by chunk sizes and benchmarks. As soon as I enable offline plugin, I get such error while running gatsby build:

failed Building partial HTML for pages - 0.175s

 ERROR #80000 

Building partial HTML failed for path "/offline-plugin-app-shell-fallback/"

This can happen if interactive elements like "useEffect", "useState", "createContext" or event handlers are used in a component without declaring the "use client" directive at
the top of the file.

Consider adding "use client" to the top of your file if your component is interactive, otherwise refactor your component so it can be statically rendered with React Server
Components (RSC).

See our docs page for more info on this error: https://gatsby.dev/partial-hydration-error



  TypeError: Cannot set properties of undefined (setting 'props')
  
  - react.production.min.js:11 apply
    [project-name]/[react]/cjs/react.production.min.js:11:385
  
  - app-shell.js:16 AppShell
    <project-dir>/.cache/partial-hydration/webpack:/project-name/.cache/caches/gatsby-plugin-offline/app-shell.js:16:29
  
  - react-server-dom-webpack-writer.node.production.min.server.js:33 P
    [project-name]/[react-server-dom-webpack]/cjs/react-server-dom-webpack-writer.node.production.min.server.js:33:135
  
  - react-server-dom-webpack-writer.node.production.min.server.js:38 ua
    [project-name]/[react-server-dom-webpack]/cjs/react-server-dom-webpack-writer.node.production.min.server.js:38:157
  
  - react-server-dom-webpack-writer.node.production.min.server.js:32 Array.toJSON
    [project-name]/[react-server-dom-webpack]/cjs/react-server-dom-webpack-writer.node.production.min.server.js:32:408
  
  - stringify
  
  - react-server-dom-webpack-writer.node.production.min.server.js:44 za
    [project-name]/[react-server-dom-webpack]/cjs/react-server-dom-webpack-writer.node.production.min.server.js:44:301
  
  - react-server-dom-webpack-writer.node.production.min.server.js:47 Immediate._onImmediate
    [project-name]/[react-server-dom-webpack]/cjs/react-server-dom-webpack-writer.node.production.min.server.js:47:95
  
  - timers:471 processImmediate
    node:internal/timers:471:21

Do you have some ideas how can I overcome this? I set all gatsby and it's plugins ecosystem to next version which seems to resolve to 5.0.0-next.9 as of this issue.

[LekoArts]

We haven't tested Partial Hydration with gatsby-plugin-offline so at this stage I'd consider it unsupported. It's not a high priority for us to get it working with gatsby-plugin-offline so for now please remove it and try again. Thanks!

[wojciechbator]

Thanks for clarification. This feature seems to really change up things performance-wise. It's visible especially on mobile

[ZeldOcarina]

Hi! How would this work with styled components?

[LekoArts]

Styling libraries like emotion or styled-components need to add support for React Server Components (which isn't an easy thing to do), until then they are unsupported.

See reactwg/react-18#110

[ZeldOcarina]

Ok cool, we will be able to use Gatsby as we always did anyways right?

[LekoArts]

As Partial Hydration is an opt-in feature, yes. If you don't activate it, it'll behave exactly the same.

[ZeldOcarina]

That's good to know, thanks a lot!

[Khaledgarbaya]

This is now available in 5.0.0: https://www.gatsbyjs.com/docs/reference/release-notes/v5.0/#partial-hydration-beta

[sibelius]

does this work with .mdx files ?

where should I put the "use client" on a .mdx file ?

[sibelius]

can we also improve the error when trying to build ?

right now the error is like this

failed Building partial HTML for pages - 0.217s

 ERROR #80000  RSC.COMPILATION

Building partial HTML failed for path "/en/modulos/transaction-fraud-prevention/"

This can happen if interactive elements like "useEffect", "useState", "createContext" or event handlers are used in a component without declaring the "use client" directive at the top of the file.

Consider adding "use client" to the top of your file if your component is interactive, otherwise refactor your component so it can be statically rendered with React Server Components (RSC).

See our docs page for more info on this error: https://gatsby.dev/partial-hydration-error



  Error: Unsupported server component type: {...}

it does not help me figure it out, what component is breaking

[tsdexter]

I just noticed this in the guide:

The Gatsby Slice API and Partial Hydration are not compatible with each other. When using Partial Hydration you can’t use Gatsby Slices and the other way around.

Is this just a current limitation or will it always be the case?

[gaearon]

Looks like this is no longer a problem — it was fixed in the docs.

[gaearon]

Checked out the preview yesterday for the first time!
It's really exciting to see RSC in a framework beyond Next.js.

A few notes that I'm sure you're aware of — but curious to hear how they fit in the roadmap.

• The biggest issue is that it's really not practically usable because it isn't supported for gatsby develop. You can try the feature in a tiny app during the build (and then fix errors and rebuild one by one) but realistically no one's going to do that. To build with this paradigm, you need to have the development behavior match the production behavior, along with all the errors you'd get, all the serialization boundaries, and so on. Is this planned in near term, long term, or not on the roadmap?

• Using async/await in a Server component does not seem to work. I would have expected to be able to just await some data from the RSC during the build, since our RSC renderer should already be doing this by default. Instead, I got an error saying Promise is not a valid React child, but I'm not sure how that could have happened — is there a bug on our side? The stack trace was incorrect so I didn't know what's causing it. Data fetching from components is an important part of RSC. I was wondering whether positioning RSC as "partial hydration" is a hint only a subset of RSC features will be supported, or whether this is just an accidental omission.

• It seems like adding getServerData breaks with RSC. Concretely, getServerData result seems to become empty. Is this a known omission? Is there a plan to switch from getServerData to RSC-style data fetching, or would you prefer to keep just getServerData, but get it working with RSC?

• The router does not seem aware of RSC, so features like useTransition won't work. This is expected, but also curious if you have more plans to integrate there.

• As a nitpick, I've noticed the initial RSC payload isn't inlined on the page, and there's a separate fetch for it. This seems to block hydration. Is there any reason for this, or is that a missing optimization?

Thanks! Again, really cool to see this first iteration, but I'm curious about what's the long term plan and where this will be going.

[wardpeet]

Hey, sorry for the late response. We've deliberated calling it partial hydration as the goal of this feature is to reduce javascript and not so much support server components fully. Server components for us is a great way for us to support islands architecture without losing context sharing and SPA support. It will take a lot of work for us to integrate the back-to-the-server part as our datalayer is not running in the cloud (yet). However, you raise some good points that we should incorporate. Also, thank you for taking the time to look at Gatsby and giving feedback.

Below is an answer on every bullet point separately:

1. We should implement RSC for gatsby-develop, it's a bit more tricky as we don't support SSR in development yet. So that's something we will get to shortly.
2. We might be running an older webpack RSC plugin version that doesn't support async-await. There is still some nuance here. For us to help incremental builds etc, we can't allow random async-awaits in react components, as we would end up with stale data. We've been considering supporting a useQuery hook that connects to our data layer instead.
3. For now, we should fix getServerData so that it keeps working.
4. Our page hydration pre-RSC was also never inlined, we use JSON files to get hydration data, and that's where RSC is stored. We can look into inlining page data/rsc data.

We're migrating inside Netlify so road mapping and fixing these bugs might take longer.

[gaearon]

Thanks for the response! (No worries about the lateness :)

We should implement RSC for gatsby-develop, it's a bit more tricky as we don't support SSR in development yet.

The connection between SSR and RSC isn't obvious to me — would you mind elaborating?

For us to help incremental builds etc, we can't allow random async-awaits in react components, as we would end up with stale data. We've been considering supporting a useQuery hook that connects to our data layer instead.

I see. I'm curious what your thoughts are on the approach Next is taking. (https://beta.nextjs.org/docs/rendering/static-and-dynamic-rendering)

[wardpeet]

The connection between SSR and RSC isn't obvious to me — would you mind elaborating?

Server Components in our codebase is wired into html generation, in our dev mode we don't run this step. The goal is to also do SSR in dev mode so it behaves more similarly to production. I think we can at least pull the RSC part out of that step and run it seperatly to at least unblock that part. It would be 1000x easier to iterate.

I see. I'm curious what your thoughts are on the approach Next is taking. (beta.nextjs.org/docs/rendering/static-and-dynamic-rendering)

What Next is doing is great but when props changes, we can't re-fetch new data from our datalayer. Next can. As the app will go to public API. Our datalayer is only available during build. That would mean data will stay stale even if props changes which could be hard for people to understand. When we have Content-Cloud ready, we can add this kind of behavior where you can run useQuery or await executeQuery anywhere in the pipeline. Even on the client when props change and a new data fetch needs to be made.

I know even in Next when RSC is used the data stays stale and only ISR can change it but we only allow you to use data-fetching at the root of a page so async-await doesn't make much sense now.

[parry84]

Hi all, I'm trying partial hydration on a small blog, but I'm facing an error apparently related to the gatsby-plugin-sharp plugin.

In particular, the build fails with error ERROR #98123 WEBPACK.BUILD-JAVASCRIPT

I added detailed info here: #37948

[morgana54]

@parry84 how have you handled it further? :)

[morgana54]

@parry84 okay, I actually solved it by shooting in the dark.

In my case, the build error was happening because I didn't have any components in my /pages directory (only 404.tsx and I was creating all of my pages in gatsby-node.ts with createPage API). After adding simple testComponent.tsx in the /pages folder, the build was successful.

Having said that, this only solved the webpack error as I've encountered another error which I couldn't resolve. This error is mentioned here: #33112 (comment). "Error: We couldn't find the correct component chunk with the name". Because of this error my pages were not interactive aka JS was not working. I have suspicions that it is somehow related to gatsby-node.ts file but did not look any further as I've abandoned Partial Hydration as it was too unpredictable/buggy in my project.