3 ms·

Hooks are incredibly confusing because of the underlying dark magic. I’ve had multiple people try to explain it to me but when I ask what does useState do under

by nojvek 7y ago

Hooks are incredibly confusing because of the underlying dark magic. I’ve had multiple people try to explain it to me but when I ask what does useState do under the hood? Can you write a simple version of it, they kinda get stuck. Initial react was super simple. A render function that renders a virtual dom tree. It’s diffed against real tree. View is simply a function of state. You could build a simple react in an hour and show the concepts. New react feels doesn’t share the same ethos of radical simplicity.

acemarke 7y ago
I can describe both of those pretty simply (I think). React uses simple objects called "fibers" to track metadata for every component in the tree. When you begin rendering a function component, React creates a linked list of hooks, and attaches the linked list to the fiber so it knows what hooks exist for that component. Each hook can save some kind of value in the linked list. For `useState`, it's the state value. For `useCallback` or `useMemo`, it's the cached value, and so on. When you render again, React loops over the hooks linked list, reads the value at that index, and returns it to your component. Shawn Wang has a talk where he builds a tiny version of hooks in a few lines: https://www.swyx.io/speaking/react-hooks/ https://www.swyx.io/speaking/react-hooks/
Izkata 7y ago
> It’s diffed against real tree. It isn't, it's diffed against the previous virtual dom, to create a set of patches, which are then applied to the real tree. This is why modifying the dom directly through refs can result in bugs.
thatswrong0 7y ago
I’ve see this argument before but I don’t get it. How is this.setState any simpler? Can you explain how class based components work in any detail? For example, why do we need to call super(props) in the constructor? There’s a whole Dan Abramov post about that one (https://overreacted.io/why-do-we-write-super-props/ https://overreacted.io/why-do-we-write-super-props/)... is that really so straightforward? Or are you just talking about “pure” functional components? How would you build a full featured application with just those? I think it’s actually _less_ magical now, because of the required static order of hook invocation. This implies that each component instance has something like an array backing it that keeps track of hooks calls between renders. This array maybe could hold said state value at the index corresponding to the static ordering of that useState call. So then maybe useState just populates the initial value in the array and provides a callback which both sets the value in the array and then queues up a component re-render
gombosg 7y ago
> I ask what does useState do under the hood? Honestly I don't care at the moment since I'm a user and not the developer of the framework. But hooks feels so much simpler for me - I can reason about what the component does instead of what framework lifecycle methods it goes through.
rebotfc 7y ago
Do you really need to know how useState works under the hood if you know how to use it, reason about it and what its limitations are?

by nojvek 7y ago

acemarke 7y ago

I can describe both of those pretty simply (I think). React uses simple objects called "fibers" to track metadata for every component in the tree. When you begin rendering a function component, React creates a linked list of hooks, and attaches the linked list to the fiber so it knows what hooks exist for that component. Each hook can save some kind of value in the linked list. For `useState`, it's the state value. For `useCallback` or `useMemo`, it's the cached value, and so on. When you render again, React loops over the hooks linked list, reads the value at that index, and returns it to your component. Shawn Wang has a talk where he builds a tiny version of hooks in a few lines: https://www.swyx.io/speaking/react-hooks/ https://www.swyx.io/speaking/react-hooks/

Izkata 7y ago

> It’s diffed against real tree. It isn't, it's diffed against the previous virtual dom, to create a set of patches, which are then applied to the real tree. This is why modifying the dom directly through refs can result in bugs.

thatswrong0 7y ago

I’ve see this argument before but I don’t get it. How is this.setState any simpler? Can you explain how class based components work in any detail? For example, why do we need to call super(props) in the constructor? There’s a whole Dan Abramov post about that one (https://overreacted.io/why-do-we-write-super-props/ https://overreacted.io/why-do-we-write-super-props/)... is that really so straightforward? Or are you just talking about “pure” functional components? How would you build a full featured application with just those? I think it’s actually _less_ magical now, because of the required static order of hook invocation. This implies that each component instance has something like an array backing it that keeps track of hooks calls between renders. This array maybe could hold said state value at the index corresponding to the static ordering of that useState call. So then maybe useState just populates the initial value in the array and provides a callback which both sets the value in the array and then queues up a component re-render

gombosg 7y ago

> I ask what does useState do under the hood? Honestly I don't care at the moment since I'm a user and not the developer of the framework. But hooks feels so much simpler for me - I can reason about what the component does instead of what framework lifecycle methods it goes through.

rebotfc 7y ago

Do you really need to know how useState works under the hood if you know how to use it, reason about it and what its limitations are?