4 ms·

> I have to say the design of the library is just so awful and non-intuitive. Absolutely agree. But this wasn't always the case. The original class components

> I have to say the design of the library is just so awful and non-intuitive. Absolutely agree. But this wasn't always the case. The original class components were much easier to understand. A backend developer could open a .tsx file and understand what is going on, and make simple fixes. This was one of the strengths of React - it was so clean, compared to Angular and other frameworks. But then they introduced hooks and messed it up. Now it is not intuitive in the least. Hooks makes some things easier but the cost in terms of loss-of-intuitiveness is huge. The other mistake Facebook is making is assuming that performance is the most important attribute of a UI framework. It is not. For 99.9% of developers the original React was already fast enough. They should have focused on making the mental model cleaner, and smoothing some of the roughness of the lib such as updating the props of a stateful component, handling deeply nested objects in the state without making entire copies of the data and so on.

HeyImAlex 4y ago
I don’t think it was done for performance, hooks just compose much better than class components. Definitely a trade off in terms of blank-slate intuition, but it unlocked a lot of things in the realm of reusability.
- foomatic 4y ago
  What does "compose much better" mean?
  - HeyImAlex 4y ago
    copy/paste from another comment: Hooks compose, whereas side effects and memoized values sprinkled through component constructors and lifecycle methods do not. For example, the equivalent of useEffect required calls inside of componentWillMount, componentDidUpdate, and componentWillUnmount. You try and make something like this re-usable and you’ll be leaking details of your implementation across the whole component via inclusion in these lifecycle methods, not to mention any data you’re shoving onto the component instance. But it’s still doable. Now, what if you wanted to use this re-usable behavior inside of another re-usable behavior? It gets complicated fast! Now your library needs to expose the lifecycle-updating methods of the underlying library, leaking details all the way down. Hooks are opaque from the perspective of lifecycle, while still having access to all the same… hooks.
    - foomatic 4y ago
      Oh ok. I'd agree Hooks compose much better then. But there was no attempt or consideration at compositional API for class based components besides getting rid of it entirely and then adding functions that hook into the nether nether. > For example, the equivalent of useEffect required calls inside of componentWillMount, componentDidUpdate, and componentWillUnmount. Yeah from what I recall this was the prime motivational example given in the React docs for introducing hooks. It's a legit problem. But hooks and getting rid of class based components is not the only solution. In classical OO are also well worn solutions along the lines of hooks, they just work with classes / objects with interfaces still. It's somewhat frustrating that this is never even considered.
- captainmuon 4y ago
  It depends, they compose better until they don't. It is easy to mess hooks up if you do not call them in the right order, especially if they are nested (composed) in other functions. You need discipline to use them correctly. Ironically they could have prevented this by making them more functional. Instead of some magic hidden state, you should have to always pass a context to them, and you should have to give every hook a unique name or a Symbol().
  - HeyImAlex 4y ago
    I know they considered “keyed” hooks, but that api is a lot more verbose since you need to key _every_ hook you use, and hooks internally need to create a sub-hook context / namespace to avoid collisions which either needs to be managed manually _or_ means you can’t use plain functions as hooks (there would be some createHook function you’d run instead).
SPBesui 4y ago
> The original class components were much easier to understand. Class components only made you feel like they were easier to understand because the method names indicated an intuitive lifecycle. But the reality under the hood was almost certainly different than your mental model because the method/event handler names were actually deceptive. Hooks are much closer to the metal, so to speak. > A backend developer could open a .tsx file and understand what is going on, and make simple fixes. They might assume they knew what was going on and how their "simple fixes" would affect execution, but that would probably be naïve. But that goes for anyone jumping into any codebase for a platform/library that they're not familiar with. > Hooks makes some things easier but the cost in terms of loss-of-intuitiveness is huge. This is fair, although I feel like the learning curve for React is only steep at first, then plateaus for the vast majority of application developers. It only gets really complicated (as anything does) when you start to get into advanced performance tuning or you're writing a library with very specific requirements. > The other mistake Facebook is making is assuming that performance is the most important attribute of a UI framework. This is simply not true. The React team has indicated many times over the years that basic, hello-world level, idiomatic React code is fast enough for the vast majority of applications ("don't worry too much about the number of re-renders," etc.). They're very anti-premature optimization as a group. Also, Hooks weren't introduced to improve performance anyway (at least that wasn't the primary motivation). > handling deeply nested objects in the state without making entire copies of the data It's not from the React team, nor is it specific to React, but have you tried immer? https://immerjs.github.io/immer/ https://immerjs.github.io/immer/
ummonk 4y ago
See this is interesting because I always found it hard to keep track of the lifecycle and state changes in React classes (especially in actual production code which quickly devolved into a tangled mess) but found functions and hooks extremely intuitive and once they were introduced. And refactoring and composability became way easier.

HeyImAlex 4y ago

I don’t think it was done for performance, hooks just compose much better than class components. Definitely a trade off in terms of blank-slate intuition, but it unlocked a lot of things in the realm of reusability.

foomatic 4y ago
What does "compose much better" mean?
- HeyImAlex 4y ago
  copy/paste from another comment: Hooks compose, whereas side effects and memoized values sprinkled through component constructors and lifecycle methods do not. For example, the equivalent of useEffect required calls inside of componentWillMount, componentDidUpdate, and componentWillUnmount. You try and make something like this re-usable and you’ll be leaking details of your implementation across the whole component via inclusion in these lifecycle methods, not to mention any data you’re shoving onto the component instance. But it’s still doable. Now, what if you wanted to use this re-usable behavior inside of another re-usable behavior? It gets complicated fast! Now your library needs to expose the lifecycle-updating methods of the underlying library, leaking details all the way down. Hooks are opaque from the perspective of lifecycle, while still having access to all the same… hooks.
  - foomatic 4y ago
    Oh ok. I'd agree Hooks compose much better then. But there was no attempt or consideration at compositional API for class based components besides getting rid of it entirely and then adding functions that hook into the nether nether. > For example, the equivalent of useEffect required calls inside of componentWillMount, componentDidUpdate, and componentWillUnmount. Yeah from what I recall this was the prime motivational example given in the React docs for introducing hooks. It's a legit problem. But hooks and getting rid of class based components is not the only solution. In classical OO are also well worn solutions along the lines of hooks, they just work with classes / objects with interfaces still. It's somewhat frustrating that this is never even considered.
captainmuon 4y ago
It depends, they compose better until they don't. It is easy to mess hooks up if you do not call them in the right order, especially if they are nested (composed) in other functions. You need discipline to use them correctly. Ironically they could have prevented this by making them more functional. Instead of some magic hidden state, you should have to always pass a context to them, and you should have to give every hook a unique name or a Symbol().
- HeyImAlex 4y ago
  I know they considered “keyed” hooks, but that api is a lot more verbose since you need to key _every_ hook you use, and hooks internally need to create a sub-hook context / namespace to avoid collisions which either needs to be managed manually _or_ means you can’t use plain functions as hooks (there would be some createHook function you’d run instead).

SPBesui 4y ago

> The original class components were much easier to understand. Class components only made you feel like they were easier to understand because the method names indicated an intuitive lifecycle. But the reality under the hood was almost certainly different than your mental model because the method/event handler names were actually deceptive. Hooks are much closer to the metal, so to speak. > A backend developer could open a .tsx file and understand what is going on, and make simple fixes. They might assume they knew what was going on and how their "simple fixes" would affect execution, but that would probably be naïve. But that goes for anyone jumping into any codebase for a platform/library that they're not familiar with. > Hooks makes some things easier but the cost in terms of loss-of-intuitiveness is huge. This is fair, although I feel like the learning curve for React is only steep at first, then plateaus for the vast majority of application developers. It only gets really complicated (as anything does) when you start to get into advanced performance tuning or you're writing a library with very specific requirements. > The other mistake Facebook is making is assuming that performance is the most important attribute of a UI framework. This is simply not true. The React team has indicated many times over the years that basic, hello-world level, idiomatic React code is fast enough for the vast majority of applications ("don't worry too much about the number of re-renders," etc.). They're very anti-premature optimization as a group. Also, Hooks weren't introduced to improve performance anyway (at least that wasn't the primary motivation). > handling deeply nested objects in the state without making entire copies of the data It's not from the React team, nor is it specific to React, but have you tried immer? https://immerjs.github.io/immer/ https://immerjs.github.io/immer/

ummonk 4y ago

See this is interesting because I always found it hard to keep track of the lifecycle and state changes in React classes (especially in actual production code which quickly devolved into a tangled mess) but found functions and hooks extremely intuitive and once they were introduced. And refactoring and composability became way easier.