6 ms·

An important point I don't see being made in the article or the comments is that hooks are meant as a more faithful (or at least less misleading) representation

by dcre 6y ago

An important point I don't see being made in the article or the comments is that hooks are meant as a more faithful (or at least less misleading) representation of what was going on under the hood in React already. The problem with the JS class representation is that people already understand what classes and instances are, and that leads to incorrect inferences about how React is working. In addition to better-organized code, the hooks abstraction is partly aimed at preventing people from making those wrong inferences. This also explains why they are uncomfortable compared to classes and functions — the point is that was a false comfort because those representations are misleading. Dan Abramov calls hooks a "missing primitive": "Why are these models insufficient to describe React? “Pure function” model doesn’t describe local state which is an essential React feature. “Class” model doesn’t explain pure-ish render, disawoving inheritance, lack of direct instantiation, and “receiving” props. What is a component? Why do you start writing it one way and then have to convert into another way? Why is it “like A but also like B”? Because it’s neither. It’s a thing of its own. A stateful function with effects. Your language just doesn’t have a primitive to express it. That’s what Hooks are. Those missing primitives. They are library-level but conceptually they are part of the “React language”. Hence the language-like “rules”. They could be syntax. They would be in Eff or Koka. But the benefits are not worth the friction it creates in JS." https://twitter.com/dan_abramov/status/1093696560280596491 https://twitter.com/dan_abramov/status/1093696560280596491 https://twitter.com/dan_abramov/status/1093697963350810624 https://twitter.com/dan_abramov/status/1093697963350810624 https://twitter.com/dan_abramov/status/1093698629708251136 https://twitter.com/dan_abramov/status/1093698629708251136

Saaster 6y ago
As a user of a library, I don't really care how it works. Under the hood it can be arbitrarily complex or simple, and please feel free to change the implementation weekly for all I care. I care very deeply about my own components, when they render, what causes them to re-render, and that I can control and reason about when they re-render. Also, stability of API (in number of years) is way more important than new whiz-bang features.
- deleted 6y ago
  [deleted]
lhorie 6y ago
It's interesting that the original appeal of React was that it was "just a view library", but now apparently it's more like a "language". It really shows the biases of the maintainers (the "just a library" thing being a philosophy I liked from vjeux, and the "language-likeness" being very obviously a heavy influence from sebmarkbage). The thing w/ "language-ness" (as opposed to "library-ness") is that additions and changes to a language tend to become more and more difficult to make over time because semantics deeply affect everything in the system, whereas well designed APIs in a library-oriented approach can be well encapsulated. I've said for a while, for example, that throwing promises for Suspense is using up "escape hatches" in JS. The rule of hooks is another one of those. Eventually, the React team will run out of escape hatches to implement "React language" semantics around the real JS semantics, and I suspect at that point sebmarkbage will move on to create a new view framework (as has been the case w/ e.g. sebmack and babel/rome, Rich Harris and ractive/svelte, etc). It'll be interesting to see if whoever steps up to maintain React at that point will be able to grok its internal complexity, and to see how the community reacts to a rift when their favorite view library team pushes for one vision but the moved-on "rockstar facebook engineer" pushes for a different vision. EDIT: fixed name confusion (thanks, swyx!)
- swyx 6y ago
  > and the "language-likeness" being very obviously a heavy influence from sebmack just a minor correction, you probably mean seb markbage, who works on React, not seb mackenzie, who made Babel and now Rome and i dont think was ever on the React team. i agree that when seb markbage leaves, it will be a big test of React's legacy. I've called it the "Ship of Theseus" moment for React.
  - desert_boi 6y ago
    Got a link to Rome's docs? Babel is a little easier to google for.
    - holler 6y ago
      https://github.com/facebookexperimental/rome https://github.com/facebookexperimental/rome
traderjane 6y ago
> A stateful function with effects. Your language just doesn’t have a primitive to express it. I wonder what about generator functions?
- lhorie 6y ago
  Yep, there was even a library making the rounds recently that leverages them: https://crank.js.org/ https://crank.js.org/
  - hombre_fatal 6y ago
    Another example: Redux Saga has been using them in React for a long time. https://redux-saga.js.org/ https://redux-saga.js.org/
- dcre 6y ago
  I don't see how generators would change anything here. "with effects", "stateful", and the integration between the two are all equally important in the statement.
  - williamdclt 6y ago
    Well generators are a good primitive to represent "stateful" "functions" "with effects". The concept of hooks, which somehow give the control back to React to do something, map marvelously to react. I'd be surprised if generators didn't come into React at one point or another
  - orange8 6y ago
    There are two different concepts as I see it, please correct me if your definitions differ. "stateful": A function that has state, i.e. can store data "with effects": A function that modifies data outside its own scope Normal JS functions (as opposed to arrow function) already do this: function foo(){}; foo.state = bar; Generator functions take it a step further, where the function remembers internal state between calls.
  - traderjane 6y ago
valand 6y ago
> The problem with the JS class representation is that people already understand what classes and instances are, and that leads to incorrect inferences about how React is working. The same goes for hooks. People already understand what functions and js scope are and that leads to incorrect inferences about how hooks work. Even more severe, newcomers who learn hooks while learning JS at the same time will get deformed perspective on how functions and scope work in JS outside of React world.

by dcre 6y ago

Saaster 6y ago

As a user of a library, I don't really care how it works. Under the hood it can be arbitrarily complex or simple, and please feel free to change the implementation weekly for all I care. I care very deeply about my own components, when they render, what causes them to re-render, and that I can control and reason about when they re-render. Also, stability of API (in number of years) is way more important than new whiz-bang features.

deleted 6y ago
[deleted]

lhorie 6y ago

It's interesting that the original appeal of React was that it was "just a view library", but now apparently it's more like a "language". It really shows the biases of the maintainers (the "just a library" thing being a philosophy I liked from vjeux, and the "language-likeness" being very obviously a heavy influence from sebmarkbage). The thing w/ "language-ness" (as opposed to "library-ness") is that additions and changes to a language tend to become more and more difficult to make over time because semantics deeply affect everything in the system, whereas well designed APIs in a library-oriented approach can be well encapsulated. I've said for a while, for example, that throwing promises for Suspense is using up "escape hatches" in JS. The rule of hooks is another one of those. Eventually, the React team will run out of escape hatches to implement "React language" semantics around the real JS semantics, and I suspect at that point sebmarkbage will move on to create a new view framework (as has been the case w/ e.g. sebmack and babel/rome, Rich Harris and ractive/svelte, etc). It'll be interesting to see if whoever steps up to maintain React at that point will be able to grok its internal complexity, and to see how the community reacts to a rift when their favorite view library team pushes for one vision but the moved-on "rockstar facebook engineer" pushes for a different vision. EDIT: fixed name confusion (thanks, swyx!)

swyx 6y ago
> and the "language-likeness" being very obviously a heavy influence from sebmack just a minor correction, you probably mean seb markbage, who works on React, not seb mackenzie, who made Babel and now Rome and i dont think was ever on the React team. i agree that when seb markbage leaves, it will be a big test of React's legacy. I've called it the "Ship of Theseus" moment for React.
- desert_boi 6y ago
  Got a link to Rome's docs? Babel is a little easier to google for.
  - holler 6y ago
    https://github.com/facebookexperimental/rome https://github.com/facebookexperimental/rome

traderjane 6y ago

> A stateful function with effects. Your language just doesn’t have a primitive to express it. I wonder what about generator functions?

lhorie 6y ago
Yep, there was even a library making the rounds recently that leverages them: https://crank.js.org/ https://crank.js.org/
- hombre_fatal 6y ago
  Another example: Redux Saga has been using them in React for a long time. https://redux-saga.js.org/ https://redux-saga.js.org/
dcre 6y ago
I don't see how generators would change anything here. "with effects", "stateful", and the integration between the two are all equally important in the statement.
- williamdclt 6y ago
  Well generators are a good primitive to represent "stateful" "functions" "with effects". The concept of hooks, which somehow give the control back to React to do something, map marvelously to react. I'd be surprised if generators didn't come into React at one point or another
- orange8 6y ago
  There are two different concepts as I see it, please correct me if your definitions differ. "stateful": A function that has state, i.e. can store data "with effects": A function that modifies data outside its own scope Normal JS functions (as opposed to arrow function) already do this: function foo(){}; foo.state = bar; Generator functions take it a step further, where the function remembers internal state between calls.
- traderjane 6y ago

valand 6y ago

> The problem with the JS class representation is that people already understand what classes and instances are, and that leads to incorrect inferences about how React is working. The same goes for hooks. People already understand what functions and js scope are and that leads to incorrect inferences about how hooks work. Even more severe, newcomers who learn hooks while learning JS at the same time will get deformed perspective on how functions and scope work in JS outside of React world.