Is there a way to hydrate a redux slice with the store's state obtained during SSR?

In the readme, section How It Works, it is mentioned that

[During SSR] connected components may alter the store’s state, but the modified state will not be transferred to the client.

However, I have a redux slice (I’m using redux toolkit) that has the specific role of determining which fonts should be preloaded, which is only useful in the initial HTML. I’d love for the client-side logic to be just “keep whatever state was determined server-side.”

Is there any way to hydrate the state (of a slice) with the SSR’s altered store’s state? I’d love a clean solution, but TBH I’d really appreciate a hacky one too!

Thanks!

---

PS: I’m asking because the logic necessary to dynamically determine which fonts need to be preloaded based on which components are used in the page requires one “synchronous” dispatch right inside each render function, which the execution time of each component to 5-10ms instead of <1ms on first render.

[kirill-konshin]

The problem is that there are no lifecycle methods that can get the state after render, only before, in normal Next.js lifecycle hooks.

You should not “redo” the work that’s already done on server, just make sure your server-rendered components are not writing the state, then your client during initial render will get the server state in a proper form. Then you can add client-only components that would do their portion of work.

[Sheraff]

As far as I understand, this only allows you to create a server-side state from the request itself, not from the render pass. But during SSR, connected components can alter the state.

Basically what I’m going for is to not redo client-side the work that has already been done server-side.

However, one of the reasons I want to avoid redoing the work client slide is because for connected components to alter the redux state during SSR, you need to synchronously dispatch redux actions, which is extremely suboptimal in terms of react perfs (component renders that usually take 0.1ms go up to 10ms) and feels hacky. It feels like I could allow that server-side if the resulting page is cached and the work isn’t repeated client-side. But it’s not a really good idea either.