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

31–37 of 37 posts

Re: React: The Perils of Rehydration

#31

Post by boubiyeah »

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,…

I understand all the hook rules and all the gotchas around stale closures. But I don't want to have to deal with those as part of my everyday, regular programming, it's just stupid. React is no longer productive and hooks are way out of control. Did you know hooks are even more stupid with concurrent mode on?

Re: React: The Perils of Rehydration

#32

Post by technobabbler »

literallyaduck wrote: post #25

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 t…

I think this is overstating the case a bit? In Next.js, it's pretty straightforward (and useful, really): the page gets its initial data injected at build time and served as HTML. It's static and stays that way until and unless you purposely add in dynamic elements on the page using useEffect or similar.

It's not really any different than, say, using PHP to generate the HTML and then using Javascript for clientside interactivity, with or without AJAX. That's been the paradigm for decades now. What NextJS gives you is the ability to do use that same paradigm in a single language, React.

Architecturally it's not really all that different, but in terms of dev experience, Next.js + Vercel is SO much better than having to maintain a LEMP stack. Just code the frontend against some CMS or other data store, push to git, and done!

Re: React: The Perils of Rehydration

#33

Post by pie6k »

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,…

Well I love hooks

Re: React: The Perils of Rehydration

#34

Post by jfry »

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,…

I think you’re using useEffect without an actual reason to use useEffect.

I’ve worked on large react projects for 4 years and I’ve only had to use useLayoutEffect once.

Sounds to me like you need to learn how to use React as a library and not as the only solution your app uses. Guess what: you can absolutely write plain JS (or Jquery etc) alongside your React components.

Re: React: The Perils of Rehydration

#35

Post by jennings_hunter »

technobabbler wrote: post #9
msoad wrote: post #6

Earlier quoted context omitted.

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, r…

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

Are you all using the incremental static regeneration API to accomplish this?

Re: React: The Perils of Rehydration

#36

Post by technobabbler »

jennings_hunter wrote: post #35
technobabbler wrote: post #9

Earlier quoted context omitted.

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, r…

> 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. Are you all using the incremental static regeneration API to accomplish this?

> Are you all using the incremental static regeneration API to accomplish this?

Yep. It's great, if hackish. A good overview (https://www.smashingmagazine.com/2021/04/incremental-static-...) or Vercel's own docs (https://vercel.com/docs/concepts/next.js/incremental-static-...)

Vercel aside, I think Cloudflare by itself works similarly if you configure it to "cache everything", including HTML pages, on a revalidation period. I find this a great balance between serverside rendering and static builds. Specifically it allows you to rebuild certain pages as things are created/updated (new or edit blog posts, products, etc.) without having to trigger a full rebuild every single time.

Re: React: The Perils of Rehydration

#37

Post by SecondRikudo »

sebmarkbage wrote: post #27
bikeshaving wrote: post #19

Earlier quoted context omitted.

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

My primary issue is that you guys did have other options. You did. I saw the RFC thread. About 2/3s were useless "oh no" or "oh yes" comments, but about a third had suggestions and feedback, some good feedback, on how to make the stateful function API not as jarring and not as weird. You simply ignored it all, since you already had an API in mind (and perhaps already did most of the work, I don't know)

That you thought (correctly) that an eslint package of rules was necessary to prevent people from shooting themselves in the foot with the gun you have provided should have been a hint that it's not good API.

Post reply on HN