I initially had a few, but after making sure they weren't just learning curve exasperations in disguise, I realized they all boil down to that they should've just started out with this and never had any class components.

I often see developers mix up classes and functional components with hooks in abominable ways, and every pitfall to hooks I can find just boils down to improperly brackish OO class model polluted thinking.

Agree, "More Stuff to Learn" isn't really a critique of hooks, it's a critique of learning.

TFA addresses this: it qualifies by saying learning is good as long as it's useful outside of whatever narrow scope they appear. The real criticism in that section is that hooks (and e.g. gotchas related to things like useEffect, stale closures, etc) are non-transferrable knowledge.

As others have said, I still don't really think it's applicable because learning hooks takes an hour or two, but to try and address that point: I don't really think the knowledge is non-transferable at all.

There's two aspects to learning hooks:

1. Learning the API. This is not a "conceptual" part of learning but rather "this function name does this thing". This is the same with learning any programming API and is almost always non-transferrable (with the minor exception of some open standards, except that varying implementations of them still tend to have quirks).

2. Learning the patterns and concepts around applying that API to problems. As far as I've seen just from TFA examples, they're very widely applicable. Memoization is widespread. Functional style is widespread. The most complex stuff handled by the quoted examples is maintaining state in nested hashtables, which is such a widespread concept that observable/immutable libraries like MobX et al & ImmutableJS et al have been written pretty much focused entirely on this problem space.

Yeah, I don't really get this criticism in regards to hooks. I think it took me maybe an hour to learn them. That's basically nothing.

I've never* used hooks and I only got 1 question wrong in the author's Google Forms quiz (would've been 2 wrong, but bullet point 4 had already signposted the object equality gotcha).

So there doesn't seem to be a huge amount to learn in hooks as far as I can tell.

* I am an experienced React developer but haven't had much opportunity to work with it in the past 2 years.

It would be amazing if JS could have object equality in a performant way. I'm not sure if Python does anything interesting under-the-hood, but identical Python dicts have deep equality just fine. That would make hooks great in my opinion, where as right now they are just good. Dealing with object non-equality is like 90% of the friction I experience with hooks. Any pattern that requires me to reorganize my code (e.g. passing in individual parts of an object rather than just the whole object to the dep array) is an inelegant pattern, imo.

This.

The article would be completely contentless if not for pointing out the genuine pain that is JS object equality (the issue is that this is a JS pain and not a React pain: hooks just makes it more apparent).

The only thing I'll say is that battling with this pain has tended toward my inventing less generalised but more readable/maintainable/elegant solutions to most individual problems where I've encountered it. e.g.:

- object equality would solve this problem easily :(

- maybe I should've enforced strict immutables throughout?

- oh maybe I could approach it differently. Yes, let's try solution X

- hmm solution X isn't very reusable but it sure is clear and intuitive to read

Not sure if it would fit with your use case, but for me, immer.js has been a game changer in terms of object equality/mutability.

https://immerjs.github.io/immer/docs/introduction

Once all state/object changes are being updated this way, a simple === can check for object equality. It's so useful, it makes me wish this was baked into the language itself.