Why Do React Hooks Rely on Call Order?

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).<p>Well the NPM report showed us the trends. Every major fad peaks around 5 years in the making in JS land and then it fades away. We are halfway through. We just have to sit through the next 3-5 years.

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 <i>that</i> scary) with the keys being the Symbols passed to useFormInput. Or am I missing something in the explanation?

I’m surprised Reagent’s ratoms weren’t an inspiration. They give you a lot of Hooks functionality largely through Clojure’s native atom.

Re: &#x27;Flaw #6: We Still Need a Linter&#x27; (first example):<p>Could the &#x27;primitive&#x27; hooks (useState, useEffect, etc) walk up `arguments.callee.caller.arguments.callee.caller...` grabbing function names until you hit a React function? Then use the names to create a &#x27;composed&#x27; key automatically? It still doesn&#x27;t solve the problem of a function using the same hook twice in one function, but it might solve the problem of collision across custom hooks.<p>Example:<p><pre><code> function useCount() { const [count, setState] = useState(0) return { count, increment: () =&gt; setState(count + 1)}; } function useCountPlusOne() { const {count: baseCount, increment} = useCount() return {count: baseCount + 1, increment} } function MyHookComponent() { const { count, increment } = useCountPlusOne() return ... } </code></pre> Would give you a key of `useState(useCount(useCountPlusOne(MyHookComponent)))` without the end user having to futz around composing the key manually. At this point you could probably even forego the &#x27;use*&#x27; convention<p>It&#x27;s still pretty magical, but the magic seems more abstracted. In general I&#x27;ve really liked hooks, and I&#x27;m willing to put up with the wackiness (although testing them with enzyme is a big PITA right now).<p>Thanks for the article :)

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:<p>1) any function that calls a hook function has a red colour<p>2) any function that calls a red coloured function has a red colour<p>3) if you ever have ever call a red coloured function in a conditional branch then bad things are going to happen<p>if you have nested functions calling hooks then you can change the order of hooks without even realising hooks are being called which is dangerous. this &#x27;nesting transparency&#x27; where callers aren&#x27;t forced to know about the hook behaviour of their sub-functions is also used as defence in the blog for relying on call order. heh

My gut feeling tells me that introducing hooks is going to end badly.<p>If there&#x27;s no patently obvious advantage but you have to rely either on convention or an additional pool of knowledge then most junior (or generally less skilled) developers cannot be trusted to use the given thing properly.<p>I&#x27;ve seen this happen with observables - sure you can do a lot of new stuff with them but they are only clearly more useful than say promises in a handful of cases.<p>Thid trend of producing tools which are powerful in the hands of the best but hard to use for beginners worries me. In the long run this makes development more expensive, not less.

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<p><pre><code> function MyReactComponent() { const [ [width, setWidth], [name, setName], ] = React.use( [useWidth], [useName, &#x27;alice&#x27;], ); return &lt;div&gt;{width} {name}&lt;&#x2F;div&gt; } </code></pre> 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 you have to pass the functions in with a specific order at the top of the component.

Sticking to attributes on classes doesn&#x27;t have this ordering issue, because construction only happens once.<p><pre><code> class Form extends ReactishComponent { name = this.useState(&#x27;Mary&#x27;) surname = this.useState(&#x27;Poppins&#x27;); width = this.useState(window.innerWidth); constructor () { this.useEffect(() =&gt; { const handleResize = () =&gt; this.width.set(window.innerWidth); window.addEventListener(&#x27;resize&#x27;, handleResize); return () =&gt; window.removeEventListener(&#x27;resize&#x27;, handleResize); }) } handleNameChange = e =&gt; this.name.set(e.target.value) handleSurnameChange = e =&gt; this.surname.set(e.target.value) render () { return ( &lt;&gt; &lt;input value={this.name.get()} onChange={this.handleNameChange} &#x2F;&gt; &lt;input value={this.surname.get()} onChange={this.handleSurnameChange} &#x2F;&gt; &lt;p&gt;Hello, {this.name.get()} {this.surname.get()}&lt;&#x2F;p&gt; &lt;p&gt;Window width: {this.width.get()}&lt;&#x2F;p&gt; &lt;&#x2F;&gt; ) } }</code></pre>

Hooks reminds me of tensorflow scopes a little bit, in python:<p><pre><code> with tf.variable_scope(&quot;foo&quot;): with tf.variable_scope(&quot;bar&quot;): v = tf.get_variable(&quot;v&quot;, [1]) assert v.name == &quot;foo&#x2F;bar&#x2F;v:0&quot; </code></pre> `v` tensor here will have a generated human readable unique name here: &quot;foo&#x2F;bar&#x2F;v:0&quot;<p>It seems with hooks, react uses call order to derive the unique &quot;leaf&quot; hook id for runtime resolving its implementations. However, it would be nice if react hooks can automatically provide a similar human readable &quot;hook id&quot; (even if only for dev&#x2F;debug build).<p><pre><code> function useWindowWidth() { const [[width, setWidth], stateId] = debug(useState); assert(stateId === &quot;useWindowWidth&#x2F;state&#x2F;:0&quot;); useEffect(() =&gt; { ... }); const [_, effId] = debug(useEffect, () =&gt; { ... }); assert(effId === &#x27;useWindowWidth&#x2F;effect&#x2F;:1&quot;); return width; } </code></pre> This will definitely help for nested custom hooks..

Isn&#x27;t the ID problem just a question of the type of the ID?<p>Sure strings would have collisions, but symbols wouldn&#x27;t.

&gt; <i>Flaw 2: One common suggestion is to let useState() accept a key argument (e.g. a string) that uniquely identifies a particular state variable within a component.</i><p>I tried asking about that earlier here on HN[0], nice to finally at least get an explanation. The tldr is name clashes when reusing hooks. A valid concern, I think they should be more upfront about the reasoning instead of &quot;hooks are magic, don&#x27;t use them in these ways&quot;. That would make it easier to accept.<p>[0]: <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=18640612" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=18640612</a> (and the blogpost in the answer didn&#x27;t really answer it)

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