Great article, couldn't agree more with them.
Great article, couldn't agree more with them.
Yes, seriously. Have you used it for more complex components? You can split your effects across multiple useEffects, and have a guarantee that they run completely independently of each other (especially since you know what their dependencies are). Compare that to lifecycle methods: you only have one per component. All your effects concerned with setup have to be piled into the same function, and their associated teardowns have to be elsewhere in another method. How do you audit a behavior's logic? How do you reuse that behavior in another component? It's not easy, and you can cause weird bugs depending on the order in which you run them.
Compare that to useEffect. Setup and teardown in the same function, which allows it to focus on just one behavior. And if you need to, it can be trivially pulled out into its own hook and reused across all your components.
For the cases when this is not possible, I agree, useEffect works better than classes lifecycle methods. But do you really want a system which caters to a small percent of use-cases at the expense of readability in others? And the improvement, to my eyes, is not that big anyway.
The hooks are my main gripe with React, but as the OP, I don't see a better alternative either - at least not one that would be worth a rewrite.
What am I using? What is the effect?
The effect.
> What is the effect?
The state-modifying (and thus side-effect-producing, or simply “effectful”) function passed as the first argument to useEffect.
Most of hooks could have been done incrementally on top of classes.
I also don't think this would be possible. Hooks are based on closures and injected state, which you can't do in a class since separate methods won't share the closure.
A lot of third party hooks are really good though, being able to hook a dependency rather than create higher order components saves a lot of time and is conceptually much easier.