3 ms·
I find that most the most common situation where a class component seems simpler is because the component is broken -- e.g. someone took a shortcut and assumed
by ng12 7y ago
I find that most the most common situation where a class component seems simpler is because the component is broken -- e.g. someone took a shortcut and assumed a prop would never change, made assumptions about the comparisons needed in `componentDidUpdate`, or didn't handle race conditions.
Personally I'm at the point were I think hooks have been vetted enough that I'm comfortably recommending functional components in all situations. I teach a short "Intro to React" workshop and at this point I don't even mention class components except for a very brief FYI at the end, and even that is mostly in case developers encounter class components in Stack Overflow.
- davnicwil 7y agoI mostly agree with this, and I also prefer using functional components whenever possible, but I think there are still situations where the mental model of class components with their lifecycle hooks is a much better fit for a problem, at least for me. These tend to come up rarely, but it'll be things like super imperative side-effect controlling components that, for instance, hook into non-React libraries (3D graphics libs, or 3rd party vanilla JS widgets, for example) via escape hatches. In those scenarios, you're very much in imperative mode, as opposed to declarative mode. Functional components and hooks excel at declarative mode, which most web app code is. Class components with their implicit statefulness and lifecycle hooks model however excel at imperative mode, so when you need that, they are for me the better solution.