This is the kind of stuff that makes me really love hooks. I've been able to refactor so much code cleanly -- complicated data fetching logic, ugly parts of my Redux store, confusing HOCs, window.setInterval spaghetti, etc. Really excited to see more high-level hooks get published.
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.
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.
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.
> I tend to be "behind" on the latest and greatest in my frontend Dev work. Usually picking stuff up 1 or 2 years after the initial hype.
I think this is a really bad strategy. Just as you shouldn't dive head first into some tool/pattern just because it's the hot new thing, you shouldn't ignore technologies just because they haven't "matured" yet. Some of the "latest and greatest" can really boost your productivity and even make your work more enjoyable and entertaining. Also, if you're paying close attention to the "latest and greatest", you, as a smart and seasoned developer will be able to lead your coworkers away from the hype train when you need to (rather than them leading you onto it).
Having a very big toolkit has certainly served me very well as a developer. Be pragmatic and use knowledge to your advantage. This isn't an industry where ignorance of technologies (even if they're bad ones) has many advantages.
Sorry, but I have to disagree here specifically for the js world. The initial versions very often seem to skip the learnings of previous generations of software engineers and re-implement the same functionality and patterns using new jargon.
The effort and time spent in internalising the new jargon to understand examples and tutorials, to me, feels like a waste.
As the frameworks and libraries near version 1 or sometimes even later, they fall back to traditional tried and tested patterns, besides getting rid of obvious bugs.
So yes, like the gp, I look but don't touch until a little later. I hardly see this happening in other languages.
