No, you're not the only one. Apart from useState, which is elegant, I hate others with passion. How can a replacement for lifecycle methods be called useEffect? Seriously?
> How can a replacement for lifecycle methods be called useEffect? Seriously?
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.
Fair enough. Though, the first question is - why does the component do so many things? Do they all need to be in a single component or can you break them apart?
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.
Yeah, it's not great, but that's because it's extremely general purpose. Its name refers to function side-effects. Since you're writing your components functionally, you need to explicitly declare any effects of your function to be run appropriately. Hence: `useEffect`. The names are super generalized because hooks don't necessarily need to render anything; they're just hooks into the React scheduler, so they can even be used to manage connection state if you want.
It's not a matter of doing too many things. Lifecycle methods exist to be used, and the moment you have any behavior that requires multiple lifecycle hooks, you will run into these issues. So I'd say it's not a small-percentage of use-cases at all, and you'll often see the benefits of hooks immediately.
I find hooks make it easier to break apart components. With a class component, there are tons of hidden dependencies on those huge components. Maintenance programmers add them relentlessly. When it comes time to refactor, it's often easiest to just translate to hooks and then start breaking things apart. Why? hooks are small and self contained by nature, and they compose nicely, so you can start with a ball of hair and use regular refactoring tools (extract to function, move to file) to decompose them.
That didn't require the meta language and rules of hooks though, they could have added this.addEffect(callback, deps) or something to class components. To preserve back compat they could have added a new base class you inherit from to get access to new APIs.
Most of hooks could have been done incrementally on top of classes.
Imagine trying to debug a component that both has lifecycle methods and reactive hooks? That would be a total nightmare, especially when the same state is being updated in both places (because that would have to be allowed). Going all-in on hooks means that there are two distinct, independent ways of writing components, and you never have to deal with interactions between the two.
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.
Only if you're constrained by the existing API of hooks. Preact signals is a good example of how class components could have been improved with reactivity:
useEffect is poorly designed for sure. It's the single most common source of react bugs I've seen and most developers have to refresh themselves on it if they don't use it for more than a few months because it is totally unintuitive.
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.
Great article, couldn't agree more with them.