One pattern you might like to try in this kind of code is writing your heavy imperative logic in classes (not React class components! just normal classes), and then using Hooks very lightly to "connect" and "disconnect" things.

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

I created this library that would allow you to put all your state logic into classes: https://github.com/baron816/use-structure

Oh wow didn't expect to hear form you! Yes that's what I'm in the middle of right now actually to enable online multiplayer: everything regarding the game is in a (class-based) state machine in pure JS that can run frontend or backend and be interacted with via a websocket client (this actually helps with a11y too, navigating a board game via aria-labels was a pain in the butt), and the UI (still WIP) will be far thinner. Perhaps I'll give hooks a try again for that.

i've seen advice on the webs for useReducer instead of a lot of useState's...which feels a lot closer to the class-component this.setState().

is there a good reason not to uniformly rely on useReducer everywhere in a codebase?

Because you have to write more code. If all you have is a single variable that gets updated with no complex logic then writing a reducer seems excessively boilerplatey.

One example of this pattern is Searchkit [0] which performs most of its logic inside a singleton Searchkit class which is instantiated and passed as a prop to the root React component. A bonus is that it's easier to implement bindings for Angular, Svelte, etc. since they can rely mostly on the class and just need to call the appropriate methods exposed on its interface. For example, it looks like Searchkit now suggests using InstantSearch (react-instantsearch-dom) [1] from Algolia, i.e. an entirely different maintainer, and it creates the bindings with a `Client(new SearchKit(...))` adapter [2] around the class (see the code on the home page at [0]).

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.

[0] https://www.searchkit.co/

[1] https://github.com/algolia/instantsearch

[2] https://github.com/searchkit/searchkit/blob/main/packages/se...

I'm going through this process right now and would love to find examples of a larger open-source codebases doing this, in case anybody has references.

Yes!!

React apps should, in general, contain much less react-specific code than they tend to.

All of the “tanstack” components seems to be going this route which I’m really excited about. I tend to really like that stack and roll most other things myself.

Should make it easier to switch frameworks in the future if the need arises.

For what it's worth, we do think there is also a lot of value in building a deep vertical integration in tooling so that it can take advantage of React's unique features. A little bit about this here: https://react.dev/learn/start-a-new-react-project#bleeding-e...

I wont dispute the benefits to vertical integration, but I still think there is benefit into keeping things modular as well. I've been working on an application for the past five years that's stayed afloat partially because keeping things small and not becoming over reliant on any one library.

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.

I have had a similar experience, and feel the same way.

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.

> Are class components really on the down & out?

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 joined my current company around the time hooks reached peak hype, and whilst the team I joined were refactoring away from class components. My previous gig had used classes. My current codebase is complex (a video player) but pushed all the core logic out to Rx and custom code, rather than going deep with hooks and react ecosystem. So I’m still way more familiar with classes despite ostensibly working in a hook-y codebase.

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?

I like them too but they tend to promote shittier code. The codebases I inherit that use classes = clean, easy to follow. Ones all in with functions and React hooks = trash.

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.

> Are class components really on the down & out

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.

> Are class components really on the down & out

Class components are still the only supported way to create an error boundary. Other than that, they are pretty much dead, yes.

Until next year when it's decided hooks have gone out of fashion and need be replaced with something else, yes.

Most React codebases benefit from the simplicity of functional components, because they fit into the model most people have of websites + web apps. If you’re doing anything complex, you’re in a very small group.

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.

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?

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).

I hate the word functional components, they aren't functional and it's a deprecated wording in react since the introduction of hooks.

Did those React team members finally stop using "render functions are supposed to be pure" as design arguments?

I think that argument moved only to the returned jsx.

I find class-based components work better for some things, mainly that need to manage complicated lifecycles that hooks do a pretty bad job of.

I recommend useReducer, if you can't use Redux. Yes, it works with non-serializable objects (evenrefs if you must).

I think generally you should start with functional components, try to keep things simple, and use class components as the exception and not the rule. My own app is mostly functional components, but I did fall back on a class component in a case where I needed the lifted state of a function reference to remain current across renders.

Class components, if you want to use typescript, are a nightmare in my experience. So much boilerplate.

From the docs:

We recommend defining components as functions instead of classes.

Not dead but they are not recommended anymore.

Pull all your business logic out in to XState machines. Keep your React components as just dumb renderers.

Yes, yes they are. Next to every 3rd party library is written to only work with hooks. Every tutorial is written using hooks. The new docs (finally) but them front and centre.