Why Do React Hooks Rely on Call Order?

Post by danabramov » Thu, Dec 13, 2018, 1:33 PM UTC

thomasfoster96 wrote: post #42

genezeta wrote: post #41

Earlier quoted context omitted.

It's not really well explained in the article, but the argument against Symbols is that you (client code) have to store them somewhere for reuse in different calls. That is that, you could do... useState("someID") ...and somewhere else (* or in the same place but on a different call) again... useState("someID") ...and this indeed refers to the same item. But using a Symbol, you need to first create it, store it somew…

That’s not really all that different to everyone moving their CSS-in-JS and GraphQL queries out of a functional component body though, is it? This is kind of exactly the scenario Symbols seem to have been intended for. Also... a nitpick, but `new Symbol` always throws a TypeError. And Symbol.for() is a useful escape hatch.

Post by thomasfoster96 » Thu, Dec 13, 2018, 1:35 PM UTC

danabramov wrote: post #55

thomasfoster96 wrote: post #37

I think this post has actually pushed me back towards Symbol keys perhaps being a good idea. The useFormInput() example under Flaw 3 seems rather contrived – wouldn’t you just pass a Symbol key to useFormInput and it would then pass the key to useState, solving the supposed flaw? If you had to use useState several times in useFormInput, just use a WeakMap (they’re not that scary) with the keys being the Symbols passe…

>wouldn’t you just pass a Symbol key to useFormInput and it would then pass the key to useState, solving the supposed flaw? Then `useFormInput()` wants to add another state (e.g. `isHovered`). How are you going to compose Symbols? We get to the next flaw (manual composition is annoying and error-prone).

Post by asark » Thu, Dec 13, 2018, 1:45 PM UTC

kmarc wrote: post #21

danabramov wrote: post #2

(I edited the post title to include “React” before the “Hooks” to disambiguate. Might be worth editing the submission too!) Hope you’ll enjoy reading it.

I just briefly looked at the examples (and of course followed the twitter boom about it), but what I am not getting is that to me it looks like since useState() is against the principles of pure functional programming. I understand that it implements some kind of inversion-of-control, but just looking at the code it feels like using some global object's method which is a big no-no. Also this importance of ordering re…

Post by drabinowitz » Thu, Dec 13, 2018, 1:52 PM UTC

danabramov wrote: post #51

drabinowitz wrote: post #48

I wonder if it would makes sense to enforce hooks being called through a top level React function. To make some of the ordering more explicit function MyReactComponent() { const [ [width, setWidth], [name, setName], ] = React.use( [useWidth], [useName, 'alice'], ); return {width} {name} } admittedly, this is much less clean looking than the current proposal, but, in my mind at least, it makes it a bit more clear that…

I don't understand what exactly you're trying to solve by this (nothing prevents a user from making it conditional) but it definitely has flaw #7 (can't pass values between Hooks).

Post by k__ » Thu, Dec 13, 2018, 2:07 PM UTC

danabramov wrote: post #59

genezeta wrote: post #38

Earlier quoted context omitted.

Yes, and to some extent it is addressed in the link too (though not really well explained). Symbols do not clash, but they need to be managed/stored by client code. i.e. you need to keep the original Symbol to use it in different calls, while you can use "different equal strings". This is the argument in the article. Whether this is indeed more or less desirable than having order restrictions on calls, that's a diffe…

Symbols don't solve this without extra closure wrapper and Hook "instantiation" (described in flaw #5). Passing a Symbol to custom Hook from outside also doesn't work because a custom Hook may have more than one state. Try to convert the `useSubscription` example to your proposed API (and don't forget effects would also need "IDs") and you'll see what I mean.