5 ms·

Not sure where I stand on this. On one hand function components and hooks give a nice way to extract logic into small reusable bits, way more than with class co

by kabes 5y ago

Not sure where I stand on this. On one hand function components and hooks give a nice way to extract logic into small reusable bits, way more than with class components. But on the other hand it becomes clear that decent performance with this approach requires all kinds of tricks and each react version adds more and more of these tricks with a steep learning curve. Shame since react started out with a very small, easy to understand API and that is what made it so popular.

nathias 5y ago
What are you talking about? How did using classes instead of functions improve performance?
- handrous 5y ago
  Certain performance improvements and mitigations for common performance problems in something like React require bi-directional interaction of state and state-related events with instances of components. Classes/objects are a pretty natural fit for that, obviously. To do the same with functions, you have to... re-create parts of a class or object system, which is what they did with Hooks. That would be the "all kinds of tricks" the OP referred to. Not that going from one to the other is inherently a win, but that to match the capabilities and ergonomics that classes & objects come with out of the box for addressing state-related performance improvements & state-related features, with "functional" React, you have to resort to "all kinds of tricks", i.e. write your own version of some of the OO things you need to get the job done semi-cleanly (which is exactly what the React team did with Hooks). The result, to put it in only slightly unfair terms, is that React has enabled their community to use a really bad and half-baked OO system with bizarre syntax & behavior, all so that no-one has to use the "class" keyword sometimes. They didn't do that for funzies, but because some of the things they wanted to do, including things related to performance, required OO-like features to be workable, but for whatever reason they didn't want to rely on built-in language features for that, nor tell their community that sometimes they would have to use those built-in language features. Instead they opted for... Hooks.
- mrloba 5y ago
  In general a function component does a lot more work than a class render function. Some of it is just about handling cases that we probably should have done with classes as well, but often didn't. The result is that everything must be carefully memoized (or not, it's sometimes hard to predict). For example, should you memoize a redux selector function like useSelector(state => state.x)? Should you wrap every function in useCallback? With classes we had arrow methods that ran once, while useCallback will be run every time the function component is run. We have to continuously check that function references are stable, if it matters, and if we care enough to bloat the function with various memo calls. Now I'm not at all saying that class components are better. Hooks are mostly easier to work with. But there's no doubt that function components has me using too much brain power and lines of code on memoization. I like the new features the react team are working on, but I hope they'll eventually do something about the stable function reference problem as well.
  - deleted 5y ago
    [deleted]
KronisLV 5y ago
You know, i'm not even sure that hooks were worth all of the problems with maintainability and readability that they've caused. I don't have the slightest doubts about me being in the minority here, but i've seen a large amount of projects which attempt to use multiple state hooks per component, and as a consequence the dependency arrays become brittle as the code is changed and sooner or later you're stuck with your page being in an endless rendering loop, because your logic isn't clever enough to actually untangle all of the state to decide when it needs to change anything: useEffect(() => { ... // a whole bunch of code }, [foo, bar]); useEffect(() => { ... // a whole bunch of code }, [bar, baz]); useEffect(() => { ... // a whole bunch of code }, [foo, bar, baz]); Sure, you can be responsible with that stuff when you're the one writing the code, but when you open up someone else's project and have "the business" breathing down on your neck but have to untangle their uncommented code, you feel like some of the features are footguns in disguise. At least with shouldComponentUpdate all of the code that decides whether something should be done was in one place. You could easily comment that code out or change it. But with hooks, you need to untangle how all of the related calls to setState work and where every method for every state hook is called and why. I'm not sure that it was a good idea to decouple those.
- oaxacaoaxaca 5y ago
  For a good while I thought I was the only one who is against hooks. It's good to see there are two of us. By the looks of the other comments here, maybe even three.
  - reactspa 5y ago
    Hooks never grew on me. I pretty much stopped paying attention to new versions after React 14. KISS - keep it stupid simple. I suspect that some Devs new to JS didn't like the various definitions of "this", and Hooks was supposed to help them out.
    - azangru 5y ago
      > I suspect that some Devs new to JS didn't like the various definitions of "this", and Hooks was supposed to help them out. No, stale closures caused by hooks are more confusing than what "this" has ever been, especially since this-related problems are mitigated with fat arrows and class property assignment. No, as far as I understand, the driving force behind the hooks was the vision of the coming concurrent mode, for which class components posed some difficult problems somehow.
cageface 5y ago
I’ve found a lot of the elegance of hooks disappears when you start maintaining the dependency lists. It’s far to easy to introduce subtle bugs or huge performance regressions with innocent looking changes. Feels like we need a new language with lazy evaluation and a smart compiler that handles this for you for this paradigm to really shine.

by kabes 5y ago

nathias 5y ago

What are you talking about? How did using classes instead of functions improve performance?

handrous 5y ago
Certain performance improvements and mitigations for common performance problems in something like React require bi-directional interaction of state and state-related events with instances of components. Classes/objects are a pretty natural fit for that, obviously. To do the same with functions, you have to... re-create parts of a class or object system, which is what they did with Hooks. That would be the "all kinds of tricks" the OP referred to. Not that going from one to the other is inherently a win, but that to match the capabilities and ergonomics that classes & objects come with out of the box for addressing state-related performance improvements & state-related features, with "functional" React, you have to resort to "all kinds of tricks", i.e. write your own version of some of the OO things you need to get the job done semi-cleanly (which is exactly what the React team did with Hooks). The result, to put it in only slightly unfair terms, is that React has enabled their community to use a really bad and half-baked OO system with bizarre syntax & behavior, all so that no-one has to use the "class" keyword sometimes. They didn't do that for funzies, but because some of the things they wanted to do, including things related to performance, required OO-like features to be workable, but for whatever reason they didn't want to rely on built-in language features for that, nor tell their community that sometimes they would have to use those built-in language features. Instead they opted for... Hooks.
mrloba 5y ago
In general a function component does a lot more work than a class render function. Some of it is just about handling cases that we probably should have done with classes as well, but often didn't. The result is that everything must be carefully memoized (or not, it's sometimes hard to predict). For example, should you memoize a redux selector function like useSelector(state => state.x)? Should you wrap every function in useCallback? With classes we had arrow methods that ran once, while useCallback will be run every time the function component is run. We have to continuously check that function references are stable, if it matters, and if we care enough to bloat the function with various memo calls. Now I'm not at all saying that class components are better. Hooks are mostly easier to work with. But there's no doubt that function components has me using too much brain power and lines of code on memoization. I like the new features the react team are working on, but I hope they'll eventually do something about the stable function reference problem as well.
- deleted 5y ago
  [deleted]

KronisLV 5y ago

You know, i'm not even sure that hooks were worth all of the problems with maintainability and readability that they've caused. I don't have the slightest doubts about me being in the minority here, but i've seen a large amount of projects which attempt to use multiple state hooks per component, and as a consequence the dependency arrays become brittle as the code is changed and sooner or later you're stuck with your page being in an endless rendering loop, because your logic isn't clever enough to actually untangle all of the state to decide when it needs to change anything: useEffect(() => { ... // a whole bunch of code }, [foo, bar]); useEffect(() => { ... // a whole bunch of code }, [bar, baz]); useEffect(() => { ... // a whole bunch of code }, [foo, bar, baz]); Sure, you can be responsible with that stuff when you're the one writing the code, but when you open up someone else's project and have "the business" breathing down on your neck but have to untangle their uncommented code, you feel like some of the features are footguns in disguise. At least with shouldComponentUpdate all of the code that decides whether something should be done was in one place. You could easily comment that code out or change it. But with hooks, you need to untangle how all of the related calls to setState work and where every method for every state hook is called and why. I'm not sure that it was a good idea to decouple those.

oaxacaoaxaca 5y ago
For a good while I thought I was the only one who is against hooks. It's good to see there are two of us. By the looks of the other comments here, maybe even three.
- reactspa 5y ago
  Hooks never grew on me. I pretty much stopped paying attention to new versions after React 14. KISS - keep it stupid simple. I suspect that some Devs new to JS didn't like the various definitions of "this", and Hooks was supposed to help them out.
  - azangru 5y ago
    > I suspect that some Devs new to JS didn't like the various definitions of "this", and Hooks was supposed to help them out. No, stale closures caused by hooks are more confusing than what "this" has ever been, especially since this-related problems are mitigated with fat arrows and class property assignment. No, as far as I understand, the driving force behind the hooks was the vision of the coming concurrent mode, for which class components posed some difficult problems somehow.

cageface 5y ago

I’ve found a lot of the elegance of hooks disappears when you start maintaining the dependency lists. It’s far to easy to introduce subtle bugs or huge performance regressions with innocent looking changes. Feels like we need a new language with lazy evaluation and a smart compiler that handles this for you for this paradigm to really shine.