I wrote a few huge class component-based Apps in React and they were working like charm and were very maintainable even for junior programmers. A few days with Redux and development was as easy as in jQuery days.
Then we hired a few front-ends who started pushing functional components where possible as it became the new paradigm and recommended way of writing React apps. From my perspective there is absolutely no difference between class and functional components, class is a few lines longer and it's supposedly harder to test but I don't know exactly why because testing classes was never an issue.
A few months passed by and maintenance became a headache because suddenly functional component X, Y and Z needed lifecycle methods and those were only available in class components! But class components are bad, right? So let's update React and use newly introduced hooks.
Now instead of me and 2 juniors you need 10 seniors to maintain the apps, nobody knows what does what, it's a nightmare. Class based components and even everything redux-related is much easier to comprehend than small logic in hooks. It's extremely easy to write unmaintainable code with hooks.
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.
> 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.
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.
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.
The harder it is to reason about the code the more you're selecting for people with greater experience and capacity to decide what needs to change and what the ramifications will be.
Then we hired a few front-ends who started pushing functional components where possible as it became the new paradigm and recommended way of writing React apps. From my perspective there is absolutely no difference between class and functional components, class is a few lines longer and it's supposedly harder to test but I don't know exactly why because testing classes was never an issue.
A few months passed by and maintenance became a headache because suddenly functional component X, Y and Z needed lifecycle methods and those were only available in class components! But class components are bad, right? So let's update React and use newly introduced hooks.
Now instead of me and 2 juniors you need 10 seniors to maintain the apps, nobody knows what does what, it's a nightmare. Class based components and even everything redux-related is much easier to comprehend than small logic in hooks. It's extremely easy to write unmaintainable code with hooks.