React: The Perils of Rehydration
joshwcomeau.com
React: The Perils of Rehydration
1–10 of 37 posts
Re: React: The Perils of Rehydration
#2Honestly, it's a very frustrating aspect of modern web development that developers still have to care about this client/server split for initial render.
JavaScript, via Node, threatens to consume server-side implementations of user-facing output for no other reason than this is an annoying problem that gets even more annoying if your client and server are talking two different scripting languages.
Re: React: The Perils of Rehydration
#3If only there was a way to directly send the data when rendering the page server side...
Re: React: The Perils of Rehydration
#4If only there was a way to directly send the data when rendering the page server side...
I'd suggest you re-read this[1] section of the article -- they're talking about "server-side generation" where rendering happens at compile time, not at request time (to avoid delaying responses with on-the-fly render computation). The data you're referring to will not be available at compile time.
[1] https://www.joshwcomeau.com/react/the-perils-of-rehydration/...
Re: React: The Perils of Rehydration
#5I think the common, simpler way is to make the component itself () state-aware. So it always returns that component, but the component itself renders differently (`isLoggedIn && `) depending on some upstream state passed as a prop or a shared context via a context provider.
If you return two different tags like the author did, React won't know how to properly inject that into the DOM. They are different elements, after all.
Re: React: The Perils of Rehydration
#6If only there was a way to directly send the data when rendering the page server side...
I'd suggest you re-read this[1] section of the article -- they're talking about "server-side generation" where rendering happens at compile time, not at request time (to avoid delaying responses with on-the-fly render computation). The data you're referring to will not be available at compile time. [1] https://www.joshwcomeau.com/react/the-perils-of-rehydration/...
Yes, but how expensive it is to render on request time anyways? Is it really a better experience to send a "mostly accurate HTML" and "hydrate" it with JavaScript in client?
I am working on this kind of technologies and I totally understand how it works but I'm not convinced this is the right solution. Actual rendering on edge without all this JS soup is what big websites should do.
Re: React: The Perils of Rehydration
#7If only there was a way to directly send the data when rendering the page server side...
I'd suggest you re-read this[1] section of the article -- they're talking about "server-side generation" where rendering happens at compile time, not at request time (to avoid delaying responses with on-the-fly render computation). The data you're referring to will not be available at compile time. [1] https://www.joshwcomeau.com/react/the-perils-of-rehydration/...
Personally, and I totally recognize that I'm likely arguing a moot point, I don't conflate static-site generation and server-side rendering and I don't think they can or should be used interchangeably as the author indicates. If my site can be hosted by Nginx alone, it's not server-side rendering to me.
On the other hand, if I am paying for the overhead of running a node server to host my site, but it doesn't support this, why not? I'm very suspicious of the argument that it's to save time due to on-the-fly render costs.
It seems that Remix and perhaps React's new server-side components will be solving this problem in a much more coherent way without requiring weird hacks like this.
Re: React: The Perils of Rehydration
#8Could this happen in sveltekit?
Re: React: The Perils of Rehydration
#9Earlier quoted context omitted.
I'd suggest you re-read this[1] section of the article -- they're talking about "server-side generation" where rendering happens at compile time, not at request time (to avoid delaying responses with on-the-fly render computation). The data you're referring to will not be available at compile time. [1] https://www.joshwcomeau.com/react/the-perils-of-rehydration/...
Yes, but how expensive it is to render on request time anyways? Is it really a better experience to send a "mostly accurate HTML" and "hydrate" it with JavaScript in client? I am working on this kind of technologies and I totally understand how it works but I'm not convinced this is the right solution. Actual rendering on edge without all this JS soup is what big websites should do.
It's a cost thing... a lot easier to CDN static HTML files and only make edge calls as necessary.
In our Next.js setup, for example, all pages are served static by default and cached around the world, but every revalidation period (60 seconds or so?), one edge worker will check the data source against the upstream CMS, and rebuild that one page if needed.
That means our max edge worker and API call is 1 per minute, regardless of whether there are 10 visitors or 10 million. The others will just get the cached CDN files.
That makes it a lot more affordable.
If you had infinite budget and could pay for edge functions to re-render the page every visit, with or without caching, then more power to you. But not everyone can afford that.
Edit: Also, a secondary benefit is accessibility. Since most of the content is served as a flat HTML, those with outdated browsers/misconfigured ad blockers/javascript turned off can still see the most important part of the content. Maybe they miss some interactivity, but they can still at least read the gist of the article since that's just HTML.
Depending on your specific edge function configuration (i.e. whether it needs web workers or web sockets or such) some browsers may not load that correctly. Dangerous for that to be the only delivery mechanism. But if your edge function just masquerades as a web server and returns plain old HTTP, that shouldn't be a problem.
Re: React: The Perils of Rehydration
#10Earlier quoted context omitted.
I'd suggest you re-read this[1] section of the article -- they're talking about "server-side generation" where rendering happens at compile time, not at request time (to avoid delaying responses with on-the-fly render computation). The data you're referring to will not be available at compile time. [1] https://www.joshwcomeau.com/react/the-perils-of-rehydration/...
Yes, but how expensive it is to render on request time anyways? Is it really a better experience to send a "mostly accurate HTML" and "hydrate" it with JavaScript in client? I am working on this kind of technologies and I totally understand how it works but I'm not convinced this is the right solution. Actual rendering on edge without all this JS soup is what big websites should do.
Remix [1] solves this problem very well.
Data that is needed by a React component is declared in the same file as the component as a loader function which the server then invokes and renders into the component on the server so the client receives an HTML response with the view ready to go (server side rendering).
I distinguish between server side rendering which is a function invocation that takes place for each request as opposed to pre built HTML which isn't "rendering" anything and instead returning a static, pre-generated file.
With Remix, the client gets an HTML response the server generated with all the data it needs already retrieved (it was retrieved on the server).
The client can then run any additional client side JS but the user doesn't need to wait on the client side JS to see the content they were trying to browse.
Remix can easily be deployed to edge systems like cloudflare workers.
The services that the loader functions hit can be run somewhere else of course as well.
[1] remix.run