Having a dedicated place to process changes in props and setup/teardown logic is just generally nicer than weird dependency arrays and returning destructors from effects.
See here for some examples of how you can approach writing the same code in a few different ways -- maybe one of these styles will fit you better: https://react.dev/learn/reusing-logic-with-custom-hooks#ther...
is there a good reason not to uniformly rely on useReducer everywhere in a codebase?
There are downsides to this - you do need to think a lot more about code architecture before implementing the code, and you can get into a really messy/unmaintainable situation if you aren't careful. And you'll need to consider what state your "singleton" is tied to - is it really one per page, one per component, etc? And depending on the answer, the implications may be that this pattern isn't a great idea. But for certain use cases, it can work well.
The core premise of this pattern is separating business and UI logic, which is not exactly a new idea.
[1] https://github.com/algolia/instantsearch
[2] https://github.com/searchkit/searchkit/blob/main/packages/se...
React apps should, in general, contain much less react-specific code than they tend to.
Should make it easier to switch frameworks in the future if the need arises.
Regarding the link, I most likely wouldn't consider routing and bundling to be in that list. Sever integration currently doesn't apply to me, since our app is one of the cases where CSR makes more sense.
In the popular sense, they've been on the down and out for years now.
> It turned in to a bit of a mess until I went for a refactor into classes and everything became much more clear.
in my experience, once the logic starts to become complex, you need to develop custom hooks so that a given component stays readable.
The hooks paradigm is a lot harder once you get past the basics, but I wouldn't go back for reasons I could articulate if there's any interest.
I hate hooks. The syntax feels nice to type, but the issues outweigh the benefits for me. It’s way too difficult to understand the rendering lifecycle, the state updating, the ordering and I also find the reuse abstraction hard to follow (although I accept that might be a concentration/attention issue on my part). Conversely, it’s also way too easy to break the purity of the hook callbacks, so hooks can use state from contexts you wouldn’t expect (more an issue with custom hooks if you don’t also supply linter tooling to go with them).
Why do you prefer them?
Obviously using hooks doesn't mean it has to be shitty, I think it just brought a lot more wannabe React devs that have no experience with architecture or maintainability.
I tried to give it a real shot with hooks, but the marginal benefit they bring seems to be far outweighed by the added complexity. Add to that the mixing of paradigms with some functional components, some class-based, etc and it becomes a mess pretty quickly.
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.
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?
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).
Class components are still the only supported way to create an error boundary. Other than that, they are pretty much dead, yes.
The hook system is the parts of an OO system that React needed to be able to keep developing features & optimizations for function-based components, rather than telling their users & devs that they'd simply have to use classes for some things. It exists so they could side-line class components, rather than having to become outright reliant on them for some features. So, pretty much, yes.
We recommend defining components as functions instead of classes.
Not dead but they are not recommended anymore.