[Klonoar]

I would argue the inverse: if your project relatively simple enough that hooks don't feel messy, then it probably doesn't need to be a React app to begin with.

Class components are just (IMO) cleaner, and I find myself saddened at the level of disarray most codebases with hooks are nowadays. Enough has been written elsewhere about how hooks require one to keep more in their head; class components have an agreed up layout/structure/etc that is important in large codebases.

[dylan-m]

The most frustrating part of this is when you run into some library that is all in on hooks and insists you use hooks, but your project has been using class-based components so far. I was having a great time making a game prototype with react-three-fiber until some model loading code was just like "fuck you, use hooks" and I ended up wrapping a bunch of functional components in special ways to basically isolate the hooks stuff so I don't have to deal with the headache of it all gradually encroaching on the rest of my perfectly functioning project. It's frustrating because every time I wonder how to make it not a mess, the answer is "haha, we lied, they're barely supported; class-based components are for losers and you should feel bad."

It's just frustrating. Couldn't they have had the decency to fork / rename React for all this and leave the old branch to die instead of turning the entire space into some kind of pedantic war-zone for several years?

[Rapzid]

On a thread a while back there was a Microsoft eng who was on a team that looked into trends with bugs.

IIRC They reported that hooks were a common source of problems.

Visually they look simple but they hide a lot complex and nuanced semantics. Once you start layering and composing it becomes hard to reason about when a value updates, when a re-renders will occur, and when a value even resolves(it may take many re-renders for a value you need to finally get set).