undefined | Better HN

0 pointsazangru1y ago0 comments

> People don't bother going through official react handbook thoroughly and understanding that react is nothing more than a handful of hooks

React is 10+ years old. Hooks are about five years old. There was react before hooks; and people who hate react don't always do so because they failed to learn the hooks api...

Also, the official react documentation is, predictably, a living document that keeps changing. I guarantee you that when react hooks were introduced in 2019, they were presented as a more convenient alternative to lifecycle methods, with a near-direct correspondence between the component lifecycle methods api and the hooks api. The useEffect hook was presented as a better and more powerful componentDidMount + componentDidUpdate combo. There was no talk of "you might not need an effect", which came out of several conference talks and culminated into a separate article in the docs. The first version of that "you might not need an effect" article appeared, according to github history, in 2022, three years after the early adopters had started using hooks including the useEffect. You were never supposed to update the state during render; now you are. You were always allowed to read component class properties during render; now with useRef, you aren't. And after all these years, react still seems to be in denial that sometimes you want some actions to happen only once over component's lifetime, upon its mounting; and you have to fight with the strongly encouraged StrictMode component for that privilege...

0 comments

4 comments · 1 top-level

gloosx1y ago· 3 in thread

>There was react before hooks;

React pre and post 16.8 are two completely different libraries. I remember 2019, hooks we presented as a replacement to lifecycle methods and class-based components at all, not as alternative. The useEffect hook was presented as something which let's you split your code based on logic instead of component lifecycle, and few examples were there showing how the new effect concept better splits the async logic which was previously a solid mess inside the componentDidMount/Update.

>in 2019, they were presented as a more convenient alternative to lifecycle methods

Again, no one presented hooks as an alternative, it was strictly a replacement for class-based components which were obsoleted.

From the rest of it I see you have a very big problem with react, "you might not need an effect" article was written for folks like you. Update the state during render? what? if you need to read something during render you need to use State, and if you need a reference to a variable outside of React you use Ref; there is a clear way to make a side-effect happen only once over component's lifetime, which is to use Effect without dependencies. StrictMode component has no use other than debugging.

azangruOP1y ago

> React pre and post 16.8 are two completely different libraries.

The two apis still coexist within the same library.

> The useEffect hook was presented as something which let's you split your code based on logic instead of component lifecycle, and few examples were there showing how the new effect concept better splits the async logic which was previously a solid mess inside the componentDidMount/Update.

That is exactly what I mean by the word "alternative". As in, previously, you achieved certain results by calling componentDidMount/DidUpdate methods; now, in order to achieve same results, you would use the useEffect in a certain way.

> Update the state during render? what?

See "Adjusting some state when a prop changes" section of "You Might Not Need an Effect"

> if you need to read something during render you need to use State, and if you need a reference to a variable outside of React you use Ref

Sure. But what if during a render you want to check something in the DOM (geometry of a DOM node or something). I do not think that pre-2019 there were any guidelines that you mustn't. There weren't any such recommendations after the hooks were released either, when all we had to go by was the hooks api documentation in what now is the legacy documentation site [0]. The caution against doing this only appeared in the new react docs in 2022. My point here is that the docs change, and the patterns of usage of the library change, and what was considered ok once no longer is. This might be why some folks are complaining, even if they don't fit the "don't bother reading the docs" profile that you proposed.

> there is a clear way to make a side-effect happen only once over component's lifetime, which is to use Effect without dependencies. StrictMode component has no use other than debugging.

StrictMode unmounts and remounts every component causing every useEffect to fire at least twice. Which means a useEffect with an empty array of dependencies will execute twice, unlike in production build in which it will indeed execute just once. This makes the code in the development mode behave differently than in production mode. This also makes useEffect with an empty dependency array incapable of guaranteeing that it will execute only once.

As for the empty array of dependencies to emulate the previous componentDidMount method, this was indeed the original message in 2019. I am almost certain — though I can't find this online now — that Dan Abramov subsequently tweeted to not rely on the empty dependencies array as a guarantee that the useEffect only fires once per component's lifetime.

[0] - https://legacy.reactjs.org/docs/hooks-reference.html#useref

gloosx1y ago

I understand react is not easy for some, and this article is made for those who are finding a hard time with it. "Adjusting state when prop changes" only means your dataflow is a whack and your logic is a mess, and article explains it well. I have shipped quite a few React interfaces to production and never in my life I had to adjust the state when prop changes, this even sounds like nonsense and smells of bad react code. StrictMode mounts components twice specifically to find bugs where an effect is lacking a clean-up, good react UI means an effect can be ran 100 times with the same effect, and StrictMode helps to ensure that.

>Dan Abramov subsequently tweeted to not rely on the empty dependencies array as a guarantee that the useEffect only fires once per component's lifetime

It is very strange that you can't find online such a non-sensical tweet from Dan, because in case of effect there is no component, and it's lifetime is non-existent, there is only function, and it can be called, and it might call a side-effect or not in it's execution, depending on X or nothing. He was probably explaining that a useEffect is not equal to a lifecycle method componentDidMount – and empty dependencies mean actual side-effect of your render function without dependencies, which you still need to clean-up properly – not the shortcut to the old "component lifecycle". After 2019 the whole concept of "mounting" and "unmounting" the "component" was obsoleted and replaced with just a function and it's side-effect, which was a dramatic shift towards procedural and functional react which does work at scale from the class-based lifecycle concept which failed at scale. For some people it is harder to grasp something procedural and functional, especially if they are used to think inside some other concept or paradigm, they mess up their one-way data flow, immutability, function composition and end up in pain using react, and it can be hated for that, i agree.

pulsarmx1y ago

> As for the empty array of dependencies to emulate the previous componentDidMount method, this was indeed the original message in 2019. I am almost certain — though I can't find this online now — that Dan Abramov subsequently tweeted to not rely on the empty dependencies array as a guarantee that the useEffect only fires once per component's lifetime.

This is one of the big reasons why I personally dislike React and the community around it. They seem to envision at the start certain ways to do things, and push them to the point of being "this is how you do X". Then, after not very long at all, the old way is discovered to be bad and inefficient and buggy and hard to reason about or whatever, now do it this other way. Repeat three or four times until a new API is created or something.

This also means that going from project to project can feel very whiplash-inducing. The code you find is not even dependant on the version of React that's installed, but on how the community was feeling about the "best practices" around the time that particular project was started.

I remember when render props were a thing. Then I remember when they stopped being considered a thing and now the new thing to do was HOCs.

Things like React Router also being wildly different between versions, or at least v3 -> v4. I remember needing to find out how to achieve certain behaviour with v3, only to then try to find that the docs only existed for v4 (which was the newest at the time), and addons that helped me with my original problem also only existed for v4. (Then React Router was no longer the Best Thing, so let's all switch to Reach Router... then back to React Router when it was again considered the new hotness. I may have forgotten one or two others in there, I just stopped paying attention around that point.)

Another example is CSS scoping, which is a complete non-issue with vanilla Vue and Svelte. But in React land you have styled-components, emotion, styled-jsx, and who knows what else in which you don't write CSS, but JS that looks like CSS but not quite, enough to throw me off every single time.

The whole periodic shifting of opinions about useEffect from "this is your componentDidUpdate replacement" to "use a linter to warn you about the footguns that we can no longer fix, also use one of these hooks instead" is just one more thing that adds to the frustration of having to work with a React-based project.

I'm actually starting to wonder if Facebook isn't so much "writing" React, but "discovering" it. Much like how we didn't quite invent fire, and we had to figure out how to use it properly over many, many thousands of years.

j / k navigate · click thread line to collapse