If you look at the official React docs, on the home page, the first example you see relies on a class-based approach, not a function-based approach. Arguably, this is intentional; not a mistake.
In order to fully understand React, you have to understand what a component lifecycle is. If you start with and only ever work with a function-based approach, you can lose sight of what this means. That's important because understanding how the lifecycle works can influence certain design decisions in both types of components (and even influence whether or not to use one over the other).
What's important to understand is that hooks were created to solve a particular problem: the need for adding state (or other stateful functionality, like fetching data) to smaller, function-based components without having to resort to using a class (and bringing in the full weight of React's lifecycle methods).
There's a lot of cargo-culting around function components and using hooks. This means that for a new learner, what they see in the React documentation vs. what they see other developers doing is contrasting.
This is confusing. The truth is that, as the React docs reveal in plain words, that both function components and class-based components are valid ways of authoring React components. Where they differ is in their utility and when they're best applied relative to your application.
Are function components bad? No. They serve a specific purpose. Are hooks bad? No. They serve a specific purpose.
What's bad is that the introduction of these tools brought a "to a man with a hammer, every problem looks like a nail" scenario in tow. Instead of asking "why," the consensus shifted towards "sure why not, everybody else is doing it!"
If all you understand is the hook-based method (or rather, all you see around you is usage of the hook-based method), it's likely that method is the only way you know how to build a React-based UI.
This is problematic because it means that you do not know when a function-based approach is better than a class-based approach and vice versa.
That matters because in not knowing, you can create unnecessary messes in your codebase simply by trying to "fit in with what everybody else is doing." You waste time and energy doing something one way that can be done with the other in half the time and still be a perfectly valid approach.
The way to solve this problem is to develop an understanding of how both methods work and the nuances involved in their usage. This takes practice. You won't get it right every single time—and you don't need to—but challenging yourself will ensure you understand why the approach you're taking is correct.
What you have to avoid is being overly pedantic. There's nothing more obnoxious than the stickler who says "this is the only way to do this!" and freaks out if you don't do it that way.
My advice? Know the territory, work to understand your tools at a deeper level, and allow room for flexibility in your process so that you don't create unnecessary problems for yourself. It also needs to be said: if you find yourself unnecessarily taking the more complex path to justify your employment, you should re-evaluate your career choices.
No spam. Just new tutorials, course announcements, and updates from CheatCode.