> fun fact: You Might Not Need an Effect was inspired by a little investigation. i spot-checked random 128 useEffect calls in the Meta codebase, classified them into several groups, and 59 out 128 were unnecessary.
My own experience, on a much more limited scale, is similar. Especially developers new to React tend to write more useEffects than actually necessary. These often add unnecessary complexity and make the component much harder to understand.
I agree with this sentiment. I find that most developers seem to be stuck in thinking of their components as imperative. They expect to alter the state (dom) directly instead of describing the dom as a function of state (props).
Because of that, they quickly reach for the escape hatch that useEffect provides everytime they need to change something.
I genuinely don't know how to help my fellow team members grasp the basic concept of components better. It doesn't seem, to me, like it's something everyone gets eventually. I've actually seen far too many developers who just don't seem to get there even after long months working with component libraries.
As a side note: I don't get all the love for class components. All I remember from using them were the endless bugs because we somehow missed something on willUpdateProps or whatever. Class components could have worked but they always felt like the different life cycle methods were all cobbled together with little overall consistency (see Vue for an example of life cycle hooks done better, even if I have plenty of other gripes with Vue's design)
Indeed. React was a welcome innovation because it enabled V=f(S). That's it.
The vDom was fast enough that it made re-rendering your view on every state change possible.
Now you don't have to worry about rendering, you describe your components as pure functions and you're done with that side of things, now you "only" have to worry about the state of your app.
Seeing comments here wondering "How am I supposed to use jQuery with React otherwise?" is baffling and disheartening.
I recently reviewed an architecture on AWS that has 5 services chained together to make information flow from source to target.
There was no justification for the middle three. The volume of data, loose coupling, native support for direct integration were all there to directly connect source to target.
https://twitter.com/dan_abramov/status/1638773531881140224
> fun fact: You Might Not Need an Effect was inspired by a little investigation. i spot-checked random 128 useEffect calls in the Meta codebase, classified them into several groups, and 59 out 128 were unnecessary.
My own experience, on a much more limited scale, is similar. Especially developers new to React tend to write more useEffects than actually necessary. These often add unnecessary complexity and make the component much harder to understand.