It seems to me that the lack of a parameter explicitly indicating the component and the reliance on hook ordering to match them across calls of the component function make them a bad design, but I might very well wrong and would be happy to be convinced otherwise.
https://overreacted.io/why-do-hooks-rely-on-call-order/
https://overreacted.io/react-as-a-ui-runtime/#static-use-ord...
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.)
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-arra...
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.
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.
It's basically the magic vs explicit discussion all over again. Like usually in this discussion, the magic approach is really appealing until it doesn't work, and then the pro-explicit people will go all "told you so" on you.
I personally really prefer explicit, having cut my fingers on magic one time too often. Instead, I'll gladly create classes if the thing I'm making has its own state (of any kind).
In fact I pretty much disagree with the current trend of wanting to shoehorn everything into this idea of declarative and/or functional programming. Especially in a language like JS, functional programming and some cherry-picked ideas from OO mesh really well together. For example, if you allow me to drift a little, did you know that you can add methods to the prototype of an Immutable.Record? You can even use class syntax! More to the point, if there's one place where OO ideas shine, it's UI components. A lot of OO ideas were particularly designed and developed for UIs.
Just like "let" and "const" let me communicate to the reader whether a variable is going to change, I like how in React-land "class" and "function" let me communicate to the reader whether a component has mutable state. Hooks feels like a hack to be able to change the value of a "const" without turning it into a "let". Get over yourself, make it a "let" already.
So for me, Hooks is an attempt to throw the baby out with the bath water. I don't experience the problem it's trying to solve. I like classes when they're appropriate.
I get the argument that custom hooks allow for easier reuse than higher order components, but I think the difference is marginal; you have to wrap your mind around the exact same complexity. Plus I think higher order components themselves are overused, but that's another story.
But! The React people strike me as a rather reasonable bunch. I strongly doubt they're going to move React into a direction where you're forced to make your state (slightly more) implicit. There's too varied a community around React now. I think React with classes and React with hooks can perfectly coexist. Also if my favorite open source React tool adopts hooks and forces me to do the same here and there, then sure I might be grumpy for a few minutes but in the end, well, I'll survive.
Well... Have any "pro-explicit people" gone all "told you so" about all the magic that's going on with setState?
I don't think so. I don't think it's a binary magic vs explicit choice. I usually lean towards explicit, but as setState demonstrates, it's possible to find some kind of balance where the benefits of the magic outweigh the downsides, or at least are not that bad of a choice.
(And of course, there's the magic of the returned object not being set as the new state, but rather being merged into the previous one.)
I thought it updates the state and the re-render is what is included in a scheduled function?
> it's best practice to provide an updated function rather than a plain object
I'm guessing you mean for a global store with shared state? Local components aren't singletons.
See here: https://reactjs.org/docs/react-component.html#setstate
> setState() enqueues changes to the component state and tells React that this component and its children need to be re-rendered with the updated state.
(Emphasis mine.)
> I'm guessing you mean for a global store with shared state? Local components aren't singletons.
No, local state, the one you set using `setState`. The offical docs don't actually recommend always using an updater function, but it's the primary method they explain, and my inclination is to better be safe than sorry:
> If the next state depends on the current state, we recommend using the updater function form, instead
At least from the principle of least surprise, Hooks don't have that particular learning hump of trying to use a built-in language feature (class instance variables) and finding out the hard way that they don't work as expected.
Is this true? Maybe I'm reading it wrong but this.setState in a React.Component just transparently calls out to `this.updater`[1] where `this.updater` is injected by the particular platform library (eg react-dom). At least in react-dom/server's case, a unique `updater` object exists per-component[2], so it's effectively a private instance field; and those state changes apply to a similarly per-component `inst.state`[3]
You can also prove this by calling setState with the wrong `this`: `this.setState.call({}, {x:1})` blows up. So the `this` is required, unlike how `useState` works.
[1]: https://github.com/facebook/react/blob/aa9423701e99a194d65a8... [2]: https://github.com/facebook/react/blob/aa9423701e99a194d65a8... [3]: https://github.com/facebook/react/blob/aa9423701e99a194d65a8...
https://medium.com/@dan_abramov/making-sense-of-react-hooks-... (Ctrl-f “where React keeps the state for Hooks”)
Which is talking about where the state is stored, not the implementation detail of how setState works.
> lack of a parameter explicitly indicating the component
That's sort of the whole point. That you can write general purpose side effect functions that don't need to care about which component they're being used in. It's super easy to have a toolkit small unit testable functions that do the pretty much all the work in the application. Far easier to work with than inheritance, mixins or traits. Easier than composition, even, because this is just calling functions. If you're familiar with using Underscore or lodash, this model will feel very intuitive.
> reliance on hook ordering
This is a red herring, because we're only talking about execution ordering when the code runs. It doesn't actually matter what order I write any code in, only that when the code runs the order doesn't change between two render frames. This is as simple as don't have conditionals outside the hooks, have them inside. If you think of hooks as accessing the state register by the index of their first access, it works well as a rule of thumb.
The real problem is the impedance mismatch that the line above causes - you need to remember that hooks access the state register by order of their first appearance, not by identity. So if hook no. 3 doesn't execute on the second render for some reason, hook no. 4 will see hook no. 3's data. This goes very contrary to JS or any other programming language / paradigm I know.
It also has repercussions (https://overreacted.io/making-setinterval-declarative-with-r...) that are unintuitive, because the identity of the functions you pass into the hooks is lost as well, so you need to put them into the call-positional state register via a ref.
To be honest, I haven't hit that edge case yet, and it's easily handled once you understand the system for what it is. It is very un-intuitive to program this way, but it's not a problem most of the time.
Just remember that the identity of the state of any hook is represented only by its sequence number of execution during the first render, and you can figure out the remaining gotchas from that.
The cannot be called in conditionals and/or loops need is certainly more rare, but it's also not necessarily an exotic thing: so much of debugging and performance work in the average imperative language is often finding things called conditionally or in loops that shouldn't be and moving them up/out. Some things like setInterval or certain types of awaiting large expensive computations you almost wish you had lint errors in place to forbid them in loops (or even sometimes to forbid them from conditionals in cases where they don't happen cause subtle bugs).
I don't think this is contrary to JS at all. It's different and may take some time getting used to, but "call order matters" isn't unusual for JS (especially in the world of DOM manipulation).
The declaration parts are always static and in the exact same order for the same component.
When you see a state less function
ToggleButton = () => {
const [flag, setFlag] useState(false)
const [count, setCount] useState(1)
const useEffect(()=> {....})
return <button onClick={() => setFlag(!flag)>{flag}</button>
}
Component ToggleButton
// declarations
hasState: "flag" setterName: "setFlag"
hasState: "count" setterName: "setCount"
onEffect() { .... }
render() {
return <button onClick={() => setFlag(!flag)>{flag}</button>
}
}
class ToggleButton extends React.Component {
flag = useState(this, true)
count = useState(this, 0)
other = useEffect(this, () => {
...
})
render() {
return <button onClick={() => this.flag.set(!this.flag.current)>{this.flag.current}</button>
}
}
I tried to explain this here:
https://overreacted.io/why-do-hooks-rely-on-call-order/#flaw...
It's a different mental model. It doesn't "click" immediately for everyone but I've seen it "click" enough times for both beginners and experienced developers that I'm not worried about it.
And I'm optimistic that hooks will be great and they won't be difficult to teach to React newcomers and more junior team members. But it's not obvious to me yet that it's the case and I'll be careful about how I use the feature going forward
Thanks for all your contributions to the community, though. Not trying to be overly critical of all the hard work — just trying to fully understand use cases, maintainability implications, etc.
Folks who are into hooks probably talked to friends/coworkers excitedly about them, but have a lot less reason to broadcast their feelings about it than people who had complaints. I don't think any of the people I know who were into them did anything more than than thumbsup the RFC or like/retweet some tweets--if they even did anything public at all--even though we all followed the discussions. Personally I didn't want to add to the noise with a comment which would basically be "Yeah this looks fantastic, and all these alternative APIs being suggested seem clearly worse."
People who don't like hooks spent a lot of time writing about their issues with them and what they'd like to hear instead. I wish I could get that type of feedback on everything I wrote, I just wouldn't want to deal with that immense volume.
I don't think there's a lot of concern about hook ordering; it's hard to see that being a serious issue in practice. And it has some significant advantages over existing alternatives.
As always, programming is about trade-offs and the React team is claiming this trade-off is worth it.
function foo() {
let x = 1;
let y = 2;
x + y;
}
You don't randomly rewrite this two lines of code on every invocation of foo.
`let x = 1` and `let [x] = useState(1)` is the exact same thing.
tl;dr: The primary design goal of hooks is to support the creation of custom hooks, which can eliminate the need for higher-order components in many cases. An ideal alternative implementation would support custom hooks, without relying on call ordering, and without requiring a linter to guarantee safety. Unfortunately, there doesn't appear to be an approach that satisfies all of these requirements. Depending on call order is apparently the least-bad approach to hooks.
I just enjoy turning his sentences into blog posts. :-)
I guess even the React team itself doesn't have an answer for this, that is why they are rolling out Hooks relatively cautiously, not forcing it down to the community like what angular does with its 1.x -> 2.0 push, which I consider as a complete disaster that eventually costed it the victory of last framework revolution.
My bet will be on the later. Hooks will become a preference, and there will be a mix of hooks/classes in real world application, since rewriting using Hooks only isn't what most people see will bring immediate benefits. The React community at large from my observation doesn't have a huge issue going forward with the current API, despite being grumpy from time to time.
I think they will be the standard going forward.