Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

React: The Perils of Rehydration

joshwcomeau.com

Post reply on HN
Print view View original

21–30 of 37 posts

Re: React: The Perils of Rehydration

#21

Post by handrous »

msoad wrote: post #6
evnp wrote: post #4

Earlier 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.

My consistent experience is that sites that simply make a round trip to the server and re-render the world on every non-trivial interaction are much faster than "performant" web apps that try very hard never to request actual HTML from a server, ever.

Re: React: The Perils of Rehydration

#22

Post by throw_m239339 »

shadowgovt wrote: post #2

Honestly, 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.

XML/XSLT solved this problem. And it still works in your browser!

Re: React: The Perils of Rehydration

#24

Post by mrburkins »

bikeshaving wrote: post #19
deckard1 wrote: post #18

This is more about the perils of React switching from component classes where lifecycle methods were explicit and obvious to the multipurpose leaky abstraction known as useEffect and the hooks API. To anyone that went through the class phase, this issue is probably obvious and well known. Also, Gatsby. If Gatsby is hiding the React warnings when your SSR diverges from client side, then that's on Gatsby. It's hard eno…

Didn’t read the article, but I have to rant a little bit. Working with `useEffect()` is so fucking miserable. It’s a bit like owning a car where the gaps between the panels are just slightly too far apart; there’s always the possibility that some data is out of sync because React inexplicably decided to run a thing a tick later than you expected. “Effects” don’t actually mix with with the old class component methods,…

This 1000X's.

At this point React is mostly a jobs program. Whatever useful abstractions it initially provided has been eclipsed by bloat.

I struggle to reconcile the unnecessary complexity with the fact that it has translated into so many well paying jobs.

Re: React: The Perils of Rehydration

#25

Post by literallyaduck »

Trying to couple client server might seem like a good idea, but you are always left guessing as to how the component got in the state it is in, which defeats a lot of the stateless ideas and puts us in a bad place debugging. Express is a good idea, React is a good idea, NextJs and the like make the developers guess until they get burned enough and then by that time a new concept like hooks vs class components comes to popularity and you start the process of learning where the new pit traps are located, until the next big shakeup.

Re: React: The Perils of Rehydration

#26

Post by Aeolun »

ricardobeat wrote: post #23

I know this is way besides the point, but > Smart people realized that if we could do that rendering on the server, we could send the user a fully-formed HTML document. Is so funny to read. It’s like history never happened.

Is more like it was unreasonable to do all that work on the client side for a long while.

Then when we could, people suddenly thought it was the best thing since sliced bread.

Re: React: The Perils of Rehydration

#27

Post by sebmarkbage »

bikeshaving wrote: post #19
deckard1 wrote: post #18

This is more about the perils of React switching from component classes where lifecycle methods were explicit and obvious to the multipurpose leaky abstraction known as useEffect and the hooks API. To anyone that went through the class phase, this issue is probably obvious and well known. Also, Gatsby. If Gatsby is hiding the React warnings when your SSR diverges from client side, then that's on Gatsby. It's hard eno…

Didn’t read the article, but I have to rant a little bit. Working with `useEffect()` is so fucking miserable. It’s a bit like owning a car where the gaps between the panels are just slightly too far apart; there’s always the possibility that some data is out of sync because React inexplicably decided to run a thing a tick later than you expected. “Effects” don’t actually mix with with the old class component methods,…

My work seems to have made you angry which makes me sad.

You’ll at least be happy to learn that useEffect will be sync if the render itself was sync in React 18. Ofc if you do an async render those effects won’t work anyway and you need to do it in the event handler itself.

I doubt it’s much of a conciliation though. I agree the programming model is weird. It’s the best idea we had for what we were trying to achieve. Sorry for the trouble it has caused you.

Re: React: The Perils of Rehydration

#28

Post by ovao »

whiddershins wrote: post #8

Could this happen in sveltekit?

This specific issue: no, not likely. It is possible for a SvelteKit application to vary in execution in the `dev` environment versus production because the contexts can be somewhat different, at least with certain adapters, but this isn’t a SvelteKit issue per se.

Re: React: The Perils of Rehydration

#29

Post by nin-jin »

bikeshaving wrote: post #19
deckard1 wrote: post #18

This is more about the perils of React switching from component classes where lifecycle methods were explicit and obvious to the multipurpose leaky abstraction known as useEffect and the hooks API. To anyone that went through the class phase, this issue is probably obvious and well known. Also, Gatsby. If Gatsby is hiding the React warnings when your SSR diverges from client side, then that's on Gatsby. It's hard eno…

Didn’t read the article, but I have to rant a little bit. Working with `useEffect()` is so fucking miserable. It’s a bit like owning a car where the gaps between the panels are just slightly too far apart; there’s always the possibility that some data is out of sync because React inexplicably decided to run a thing a tick later than you expected. “Effects” don’t actually mix with with the old class component methods,…

Convenient reactivity models have existed for a long time. Someone, bring them to the react developers. https://dev.to/ninjin/main-aspects-of-reactivity-58co

Re: React: The Perils of Rehydration

#30

Post by lewispollard »

deckard1 wrote: post #18

This is more about the perils of React switching from component classes where lifecycle methods were explicit and obvious to the multipurpose leaky abstraction known as useEffect and the hooks API. To anyone that went through the class phase, this issue is probably obvious and well known. Also, Gatsby. If Gatsby is hiding the React warnings when your SSR diverges from client side, then that's on Gatsby. It's hard eno…

> This is more about the perils of React switching from component classes where lifecycle methods were explicit and obvious to the multipurpose leaky abstraction known as useEffect and the hooks API. To anyone that went through the class phase, this issue is probably obvious and well known.

I don't see how that follows, as someone who transitioned from class components to functional. A functional component is simply a function that runs top to bottom. I don't see any lifecycle issues in the example given.

Yes, if you run that top to bottom on the server and render the output to the client, it's going to return null, since there's no window object. It's obvious once you think of it as just a function, and not an OO abstraction. That they fixed it with a hook doesn't mean the only way to fix it is with a hook. It's just a misunderstanding about SSR on the author's part, I feel.

If anything, lifecycle is much more obvious now, given that you know that returning a function from `useEffect` will call it when the component unmounts, which admittedly isn't obvious without reading the docs.

Post reply on HN