4 ms·
Eeeeeasy, here is the whole journey for you: 0. People are coming to React after doing X years of that other thing, which was was not necessary related to user
by gloosx 2y ago
Eeeeeasy, here is the whole journey for you:
0. People are coming to React after doing X years of that other thing, which was was not necessary related to user interfaces at all, was not procedural or reactive
1. People are super confused by something reactive and procedural, it feels too "complex" and something messy usually comes out of their fingertips
2. People think what if they sign for React, they automatically sign for react-router react-video-player react-redux react-custom-div-tag react-img and so on, bringing a ton of unnecessary dependencies to the project and crying out loud that this "whole React framework" is too complicated and nuanced
3. People don't bother going through official react handbook thoroughly and understanding that react is nothing more than a handful of hooks, which can solve every user interface problem in an effective way. Instead they watch 10-minute video on 2x speed which tells them to npm react-router, react-redux and react-custom-div-tag
4. People end up with a monster, which makes them cringe every time they are looking at it, and they can never ship it
5. People go and produce a big rant post to spread the hate with the title "How/Why I quit React and went back to Laravel, then finally shipped", sharing it here on HN
- azangru 2y ago> 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...
- gloosx 2y ago>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.
- azangru 2y 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 https://legacy.reactjs.org/docs/hooks-reference.html#useref