4 ms·

Yes, I am experiencing similar issues as well in our codebase. Half of it is class based while the other half is now in hooks. Apparently classes are now "bad"

Yes, I am experiencing similar issues as well in our codebase. Half of it is class based while the other half is now in hooks. Apparently classes are now "bad" and therefore it should be immediately abandoned. Unfortunately this leaves us with a fractured codebase. The real pain to productivity comes when trying to onboard new developers. They have to now double their learning efforts by having to understand two programming paradigms. It's easy for them to get confused and intimidated. I don't blame them. Even I hit some level of mental fatigue of having to remember how things are done when switching between the two. What I dislike and don't understand is the lack of discipline developers have to stick with an existing library or framework. This desire to constantly hop to the next latest thing — in this case classes to hooks — ends up fracturing the codebase, making it more difficult to understand and manage. For what? A trivial gain in supposed productivity? Perhaps writing the hook itself versus a class is indeed more efficient, but the fracture in the codebase it brings, I believe, ultimately brings a net loss in productivity. Anecdotally, I am starting to get more used to hooks, but I'd prefer to go back to classes if I had the choice. I found classes are much more explicit on what is going on, especially when trying to understand the various states of render cycles. What's happening in the cycle in hooks is challenging to me. There is also a proclivity to accidentally introduce infinite loops with hooks, which was a rare problem when dealing with classes.

crooked-v 6y ago
> There is also a proclivity to accidentally introduce infinite loops with hooks, which was a rare problem when dealing with classes. That makes me quirk an eyebrow. Somebody's doing something fundamentally wrong in how they're writing the component if they're making an infinite loop happen with hooks.
- acemarke 6y ago
  I'll disagree with this a bit. It was always possible to do this in class components if you had some kind of a `setState()` call in your `componentDidUpdate` method. But, this was a rarer stumbling block. On the other hand, with hooks: - Effect hooks always run after render by default unless you specify a deps array to limit how often they re-run - It's fairly easy to queue a state update that changes one of the values in your deps array, causing the effect hook to immediately run again So, it's "fundamentally wrong" in that it's a thing you don't _want_ to do, but it _is_ a lot easier to make that mistake now.
  - crooked-v 6y ago
    If you're using setState in useEffect directly in a component then you're probably doing something wrong. All the valid use cases I can think of for functionality like that should be using a wrapping hook function, rather than re-implementing functionality separately in components.

crooked-v 6y ago

> There is also a proclivity to accidentally introduce infinite loops with hooks, which was a rare problem when dealing with classes. That makes me quirk an eyebrow. Somebody's doing something fundamentally wrong in how they're writing the component if they're making an infinite loop happen with hooks.

acemarke 6y ago
I'll disagree with this a bit. It was always possible to do this in class components if you had some kind of a `setState()` call in your `componentDidUpdate` method. But, this was a rarer stumbling block. On the other hand, with hooks: - Effect hooks always run after render by default unless you specify a deps array to limit how often they re-run - It's fairly easy to queue a state update that changes one of the values in your deps array, causing the effect hook to immediately run again So, it's "fundamentally wrong" in that it's a thing you don't _want_ to do, but it _is_ a lot easier to make that mistake now.
- crooked-v 6y ago
  If you're using setState in useEffect directly in a component then you're probably doing something wrong. All the valid use cases I can think of for functionality like that should be using a wrapping hook function, rather than re-implementing functionality separately in components.