Why Do React Hooks Rely on Call Order? • Hacker News Board

Re: Why Do React Hooks Rely on Call Order?

#51

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

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).

Re: Why Do React Hooks Rely on Call Order?

#52

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

benmmurphy wrote: post #49

relying on call order does seem kind of scary but without knowing how people structure their code using hooks its hard to know how bad it would be. for example the situation with hooks is basically: 1) any function that calls a hook function has a red colour 2) any function that calls a red coloured function has a red colour 3) if you ever have ever call a red coloured function in a conditional branch then bad things…

The "color" you're talking about is the "use" naming convention that's enforced by the linter. So if you call a Hook, you're supposed to call your function `useSomething()`, and we consider it a Hook too.

In practice we haven't seen this to cause confusion from people who actually tried this proposal for more than a few hours.

See https://reactjs.org/docs/hooks-rules.html

Re: Why Do React Hooks Rely on Call Order?

#53

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

yiransheng wrote: post #47

Hooks reminds me of tensorflow scopes a little bit, in python: with tf.variable_scope("foo"): with tf.variable_scope("bar"): v = tf.get_variable("v", [1]) assert v.name == "foo/bar/v:0" `v` tensor here will have a generated human readable unique name here: "foo/bar/v:0" It seems with hooks, react uses call order to derive the unique "leaf" hook id for runtime resolving its implementations. However, it would be nice i…

For debugging, we will show Hook tree in DevTools by capturing and parsing stack traces.

https://github.com/facebook/react/pull/14085

Re: Why Do React Hooks Rely on Call Order?

#54

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

fogetti wrote: post #7

Beg to differ, yes, implicit call order will result in huge clusterfucks. React+Redux is already causing Frankenstein apps (which is not implicitly caused by those frameworks (ok, maybe except redux) but when you throw in react-redux, react-router, redux-thunk, etc. in the mix it just deteriorates quickly). Well the NPM report showed us the trends. Every major fad peaks around 5 years in the making in JS land and the…

I'd love to debate the part about persistent call order but the rest of your comment has nothing to do with the content of my article and appears to be a generic rant.

Could you help me see how it would result in "huge clusterfucks" with an example?

Note React doesn't rely on particular call order. You can move your calls around any way you like. Just that it's persistent between re-renders.

Re: Why Do React Hooks Rely on Call Order?

#55

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

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).

Re: Why Do React Hooks Rely on Call Order?

#56

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

k__ wrote: post #34

Isn't the ID problem just a question of the type of the ID? Sure strings would have collisions, but symbols wouldn't.

You can search the article for "symbol" — there's a whole section dedicated to that. :-)

Re: Why Do React Hooks Rely on Call Order?

#57

Post by danabramov » Thu, Dec 13, 2018, 1:21 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…

I suggest you to read about algebraic effects. We don't have them in JavaScript, but conceptually that's what Hooks represent. (This is as functional as it gets.)

React has always been about taking useful ideas from functional programming and bringing it to mainstream through pragmatic choices in JS.

Your concern about the "globalness" is addressed in Sebastian's comment which is linked five times throughout the post — you should definitely check it out! https://github.com/reactjs/rfcs/pull/68#issuecomment-4393148...

Finally, don't forget you're comparing Hooks to classes. Those are hardly functional either.

Re: Why Do React Hooks Rely on Call Order?

#58

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

politician wrote: post #19

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.

Looking at the design, it's clear that the team is trying really hard to make functions look and work like classes look. Variable declarations at the top, followed by helper methods, followed by lifecycle methods. Given that classes are themselves sugar to make prototypes palatable to a broad range of developers, it's certainly a tough design task; I'm not convinced that reliance on call-index is wrong per se, but it…

>From a design standpoint, if `useState(symbol)` is acceptable (and I'm not saying it is), then `useWindowWith(symbol)` would likewise be acceptable in that it's not adding any more requirements to the interface than the vanilla version.

I think you're missing that `useWindowWidth()` could have more than one `useState()` and thus you'd need to somehow compose Symbols. Which is what the next section is about.

Re: Why Do React Hooks Rely on Call Order?

#59

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

genezeta wrote: post #38

k__ wrote: post #35

Earlier quoted context omitted.

Wouldn't symbols solve this issue?

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.

Re: Why Do React Hooks Rely on Call Order?

#60

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

danabramov wrote: post #58

politician wrote: post #19

Earlier quoted context omitted.

Looking at the design, it's clear that the team is trying really hard to make functions look and work like classes look. Variable declarations at the top, followed by helper methods, followed by lifecycle methods. Given that classes are themselves sugar to make prototypes palatable to a broad range of developers, it's certainly a tough design task; I'm not convinced that reliance on call-index is wrong per se, but it…

>From a design standpoint, if `useState(symbol)` is acceptable (and I'm not saying it is), then `useWindowWith(symbol)` would likewise be acceptable in that it's not adding any more requirements to the interface than the vanilla version. I think you're missing that `useWindowWidth()` could have more than one `useState()` and thus you'd need to somehow compose Symbols. Which is what the next section is about.

In particular, I would suggest to take the `useSubscription` example from "diamond problem" section and try to convert that whole snippet. You'll see where it falls apart.