3 ms·

While HN wasn’t convinced last time I posted this, here’s a few posts or sections that explain the static call order thing: https://overreacted.io/why-do-hooks

While HN wasn’t convinced last time I posted this, here’s a few posts or sections that explain the static call order thing: https://overreacted.io/why-do-hooks-rely-on-call-order/ https://overreacted.io/why-do-hooks-rely-on-call-order/ https://overreacted.io/react-as-a-ui-runtime/#static-use-order https://overreacted.io/react-as-a-ui-runtime/#static-use-ord... https://github.com/reactjs/rfcs/pull/68#issuecomment-439314884 https://github.com/reactjs/rfcs/pull/68#issuecomment-4393148... (Persistent Call Index section) Hope this helps, happy to answer questions. We’ve been using Hooks for several months at FB and haven’t seen confusion caused by the call order reliance. (Note Hooks don’t rely on specific call order but just on it being static between renders. Which is pretty easy to understand and reasonably enforce in practice.)

k__ 8y ago
I found it especially nice that React told me where I was doing it wrong.
palerdot 8y ago
One thing that looks 'magical' is how does the setWhatever function lets React know that state has changed and has to re-render? Is there any info/writeup on this anywhere?
- FLGMwt 8y ago
  The component renders any time the setWhatever function is called, similar to this.setState() in class components. The presumption is anything that you're storing in state is depended on by the component. If it's not, it doesn't make sense to have it in state anyway.
- danabramov 8y ago
  Pretty much the same way as this.setState in a class does. React knows which component is rendering at any point in time — so it knows which component useState() call corresponds to. I think this explanation is quite accessible: https://medium.com/@ryardley/react-hooks-not-magic-just-arrays-cd4f1857236e https://medium.com/@ryardley/react-hooks-not-magic-just-arra...
  - dvlsg 8y ago
    > React knows which component is rendering at any point in time — so it knows which component useState() call corresponds to. Personally, I think that may be the piece that makes it feel a bit magical. With `this.setState()`, usage of `this` makes me feel like I know how the component and the state are linked. With hooks, however, there's no obvious link to the component in the code. I'm grabbing `useState` off of the shared react module, `useState` is not passed into the component, and I don't have to reference the component itself at any point while using hooks. The new sets of rules you have to follow to make things line up correctly play a part, as well. Of course that may be how `this.setState()` does it anyways - you know better than I do, obviously. Maybe the usage of `this.setState()` made me feel confident in something I didn't actually understand under the hood. But at least for me, that's why `useState()` feels a bit magical at first glance compared to `this.setState()`. Not _too_ magical, and not enough to scare me away from using hooks, but still a bit.
    - danabramov 8y ago
      Yeah I totally get that. Conceptually Hooks are modeled as "algebraic effects" feature from languages like Eff and Koka. Those are essentially like resumable exceptions. With that conceptual model, `useState` is like a `throw` that goes back into React "up the stack", and then goes back into your code. Of course that's not how it works for perf and other reasons (there's no resumable exceptions in JS). But this may help the conceptual model around how we know which component it is.
sephoric 8y ago
When I first encountered hooks about a month ago, I was absolutely confused about how the `a` in `const [a,b] = useState(...)` was just a plain JS object and not some magic proxy. It took me a good hour of researching before I understood that it was because React stores state that remembers the last time it called your component. I think a 20 second well-thought-out gif would clear this up for everyone who doesn't have an hour to devote to understanding this, and I strongly recommend considering it.

k__ 8y ago

I found it especially nice that React told me where I was doing it wrong.

palerdot 8y ago

One thing that looks 'magical' is how does the setWhatever function lets React know that state has changed and has to re-render? Is there any info/writeup on this anywhere?

FLGMwt 8y ago
The component renders any time the setWhatever function is called, similar to this.setState() in class components. The presumption is anything that you're storing in state is depended on by the component. If it's not, it doesn't make sense to have it in state anyway.
danabramov 8y ago
Pretty much the same way as this.setState in a class does. React knows which component is rendering at any point in time — so it knows which component useState() call corresponds to. I think this explanation is quite accessible: https://medium.com/@ryardley/react-hooks-not-magic-just-arrays-cd4f1857236e https://medium.com/@ryardley/react-hooks-not-magic-just-arra...
- dvlsg 8y ago
  > React knows which component is rendering at any point in time — so it knows which component useState() call corresponds to. Personally, I think that may be the piece that makes it feel a bit magical. With `this.setState()`, usage of `this` makes me feel like I know how the component and the state are linked. With hooks, however, there's no obvious link to the component in the code. I'm grabbing `useState` off of the shared react module, `useState` is not passed into the component, and I don't have to reference the component itself at any point while using hooks. The new sets of rules you have to follow to make things line up correctly play a part, as well. Of course that may be how `this.setState()` does it anyways - you know better than I do, obviously. Maybe the usage of `this.setState()` made me feel confident in something I didn't actually understand under the hood. But at least for me, that's why `useState()` feels a bit magical at first glance compared to `this.setState()`. Not _too_ magical, and not enough to scare me away from using hooks, but still a bit.
  - danabramov 8y ago
    Yeah I totally get that. Conceptually Hooks are modeled as "algebraic effects" feature from languages like Eff and Koka. Those are essentially like resumable exceptions. With that conceptual model, `useState` is like a `throw` that goes back into React "up the stack", and then goes back into your code. Of course that's not how it works for perf and other reasons (there's no resumable exceptions in JS). But this may help the conceptual model around how we know which component it is.

sephoric 8y ago

When I first encountered hooks about a month ago, I was absolutely confused about how the `a` in `const [a,b] = useState(...)` was just a plain JS object and not some magic proxy. It took me a good hour of researching before I understood that it was because React stores state that remembers the last time it called your component. I think a 20 second well-thought-out gif would clear this up for everyone who doesn't have an hour to devote to understanding this, and I strongly recommend considering it.