3 ms·

This is a great strategy in many ways, because after a couple of years the 'this solves every problem' hype has mostly settled and the good, practical uses for

This is a great strategy in many ways, because after a couple of years the 'this solves every problem' hype has mostly settled and the good, practical uses for the newer pattern are usually fairly clear from consensus. I'd say use this to your advantage with hooks. They're amazing and much nicer for some things, but don't go in thinking of HOCs, render props, even class components with lifecycle methods, as something that should be replaced entirely because hooks are universally better at everything they can do. The latter are indeed cleaner than hooks, simpler, less hassle, etc in many situations - and truly, honestly, a lot of the time it's nothing more than personal preference anyway.

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 ago
  I 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.

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 ago
I 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.