9 ms·

Are class components really on the down & out? I tried going all in on hooks with a complicated app using lots of web workers and generally heavy computation an

Are class components really on the down & out? I tried going all in on hooks with a complicated app using lots of web workers and generally heavy computation and complex logic (a game). It turned in to a bit of a mess until I went for a refactor into classes and everything became much more clear. 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.

bottlepalm 4y ago
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.
phphphphp 4y ago
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.
- Klonoar 4y ago
  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 4y ago
    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 4y ago
    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).
- epolanski 4y ago
  I hate the word functional components, they aren't functional and it's a deprecated wording in react since the introduction of hooks.
  - Rapzid 4y ago
    Did those React team members finally stop using "render functions are supposed to be pure" as design arguments?
    - epolanski 4y ago
      I think that argument moved only to the returned jsx.
rkeene2 4y ago
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.
- bayesian_horse 4y ago
  I recommend useReducer, if you can't use Redux. Yes, it works with non-serializable objects (evenrefs if you must).
shmde 4y ago
From the docs: We recommend defining components as functions instead of classes. Not dead but they are not recommended anymore.
- deleted 4y ago
  [deleted]
danabramov 4y ago
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#there-is-more-than-one-way-to-do-it https://react.dev/learn/reusing-logic-with-custom-hooks#ther...
- explaininjs 4y ago
  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.
- baron816 4y ago
  I created this library that would allow you to put all your state logic into classes: https://github.com/baron816/use-structure https://github.com/baron816/use-structure
- leeoniya 4y ago
  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?
  - Marazan 4y ago
    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.
- chatmasta 4y ago
Waterluvian 4y ago
Class components, if you want to use typescript, are a nightmare in my experience. So much boilerplate.
rxhernandez 4y ago
> 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.
- the_other 4y ago
  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?
- exclusiv 4y ago
  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.
montroser 4y ago
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.
yamtaddle 4y ago
> 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.
Stevvo 4y ago
Until next year when it's decided hooks have gone out of fashion and need be replaced with something else, yes.
silverwind 4y ago
> 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.
johtso 4y ago
Pull all your business logic out in to XState machines. Keep your React components as just dumb renderers.
gherkinnn 4y ago
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.

bottlepalm 4y ago

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.

phphphphp 4y ago

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.

Klonoar 4y ago
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 4y ago
  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 4y ago
  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).
epolanski 4y ago
I hate the word functional components, they aren't functional and it's a deprecated wording in react since the introduction of hooks.
- Rapzid 4y ago
  Did those React team members finally stop using "render functions are supposed to be pure" as design arguments?
  - epolanski 4y ago
    I think that argument moved only to the returned jsx.

rkeene2 4y ago

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.

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

shmde 4y ago

From the docs: We recommend defining components as functions instead of classes. Not dead but they are not recommended anymore.

deleted 4y ago
[deleted]

danabramov 4y ago

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#there-is-more-than-one-way-to-do-it https://react.dev/learn/reusing-logic-with-custom-hooks#ther...

explaininjs 4y ago
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.
baron816 4y ago
I created this library that would allow you to put all your state logic into classes: https://github.com/baron816/use-structure https://github.com/baron816/use-structure
leeoniya 4y ago
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?
- Marazan 4y ago
  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.
chatmasta 4y ago

Waterluvian 4y ago

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

rxhernandez 4y ago

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

the_other 4y ago
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?
exclusiv 4y ago
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.

montroser 4y ago

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.

yamtaddle 4y ago

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

Stevvo 4y ago

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

silverwind 4y ago

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

johtso 4y ago

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

gherkinnn 4y ago

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.