3 ms·

Hooks had nothing to do with v8 optimizations or `this.state`. Per https://reactjs.org/docs/hooks-intro.html https://reactjs.org/docs/hooks-intro.html , the pr

Hooks had nothing to do with v8 optimizations or `this.state`. Per https://reactjs.org/docs/hooks-intro.html https://reactjs.org/docs/hooks-intro.html , the primary motivations were: - "It’s hard to reuse stateful logic between components " - "Complex components become hard to understand" - "Classes confuse both people and machines" (remembering how `this` works, code minification, method binding, etc) There's also an excellent "Why React Hooks?" post at https://ui.dev/why-react-hooks https://ui.dev/why-react-hooks that gives background details. Additionally, the React team has talked about how hooks and function components allow them to have "forks" of the component tree in various states of partial completion at a time, for use with Suspense and transition features. This works because closures capture data in a scope, whereas mutable class instances could have gotten changed and refer to a single `this` instance.

srcreigh 4y ago
One of the few reasonable comments in this thread. Hooks are better than HOCs, no this is better than managing this, and dependency arrays are better than if (this.props.fooBarBaz !== newProps.fooBarBaz || this.props.onFooBarBazChanged !== newProps.onFooBarBazChanged || …)
engineeringwoke 4y ago
> This works because closures capture data in a scope, whereas mutable class instances could have gotten changed and refer to a single `this` instance. So `this.state` is hard to optimize? > Hooks had nothing to do with v8 optimizations or `this.state`. Huh? That's what you just said. The spec makes it hard to optimize. The JIT compiler can't infer enough about the shape of the data.
- acemarke 4y ago
  You're very much misreading what I said. It's not about "optimization" in the sense of "how fast can the v8 interpreter execute lookups on the class instance" or anything like that. It's about "when this function executes, what data does it see, and did any of those values get changed out from under it in a way that could potentially break the logic"?
  - engineeringwoke 4y ago
    > It's about "when this function executes, what data does it see, and did any of those values get changed out from under it in a way that could potentially break the logic"? You're just describing the semantics of functions versus classes, and the consideration has existed long before hooks came around for exactly the reasons you describe. This discussion has also existed long before JavaScript, React, or hooks existed obviously. It's secondary to the discussion because function components have existed for a long time. None of what you're saying changes the fact that replacing classes and lifecycles with hooks was done despite the fact that 99.9% of the API users would never care about the performance implications of classes, while that is precisely why the React team made the change. JavaScript is plenty composable with classes and without nested useEffect calls, which is one of the most absurd foot gun APIs that I have seen released in my entire career.
    - acemarke 4y ago
      I'm legitimately curious. Can you point to a single actual source to cite "the React team made the change to hooks because of JS engine performance"? (and when you say "performance", you _are_ talking about literal instruction execution time / JIT behavior / etc, that sort of thing?) I'm pretty deeply tied into the React ecosystem, and I honestly can't remember _ever_ seeing that mentioned as a justification. If you can link me a reference with them saying that, I'd both be interested in reading it, but honestly surprised to see that stated at all.

srcreigh 4y ago

One of the few reasonable comments in this thread. Hooks are better than HOCs, no this is better than managing this, and dependency arrays are better than if (this.props.fooBarBaz !== newProps.fooBarBaz || this.props.onFooBarBazChanged !== newProps.onFooBarBazChanged || …)

engineeringwoke 4y ago

> This works because closures capture data in a scope, whereas mutable class instances could have gotten changed and refer to a single `this` instance. So `this.state` is hard to optimize? > Hooks had nothing to do with v8 optimizations or `this.state`. Huh? That's what you just said. The spec makes it hard to optimize. The JIT compiler can't infer enough about the shape of the data.

acemarke 4y ago
You're very much misreading what I said. It's not about "optimization" in the sense of "how fast can the v8 interpreter execute lookups on the class instance" or anything like that. It's about "when this function executes, what data does it see, and did any of those values get changed out from under it in a way that could potentially break the logic"?
- engineeringwoke 4y ago
  > It's about "when this function executes, what data does it see, and did any of those values get changed out from under it in a way that could potentially break the logic"? You're just describing the semantics of functions versus classes, and the consideration has existed long before hooks came around for exactly the reasons you describe. This discussion has also existed long before JavaScript, React, or hooks existed obviously. It's secondary to the discussion because function components have existed for a long time. None of what you're saying changes the fact that replacing classes and lifecycles with hooks was done despite the fact that 99.9% of the API users would never care about the performance implications of classes, while that is precisely why the React team made the change. JavaScript is plenty composable with classes and without nested useEffect calls, which is one of the most absurd foot gun APIs that I have seen released in my entire career.
  - acemarke 4y ago
    I'm legitimately curious. Can you point to a single actual source to cite "the React team made the change to hooks because of JS engine performance"? (and when you say "performance", you _are_ talking about literal instruction execution time / JIT behavior / etc, that sort of thing?) I'm pretty deeply tied into the React ecosystem, and I honestly can't remember _ever_ seeing that mentioned as a justification. If you can link me a reference with them saying that, I'd both be interested in reading it, but honestly surprised to see that stated at all.