Hooks seems like a right solution for a wrong problem.
How come?
With React 16.8, React Hooks are available in a stable release
31–40 of 181 posts
Re: With React 16.8, React Hooks are available in a stable release
#32Are hooks being accepted as a good design by the community? 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.
My impression is the community is mostly accepting, but some are taking a wait and see attitude until they can see it in production. 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.
Maybe it won't be an issue. However, it does go against regular advice of being explicit over magical. Depending on call order is something that immediately pops out as fishy.
As always, programming is about trade-offs and the React team is claiming this trade-off is worth it.
Re: With React 16.8, React Hooks are available in a stable release
#33Looking forward to updating my current project later today. The mess of HOCs, local state, context and props flying around have kept me busy looking for alternative frameworks in the past few years; without those it might actually start being consistently enjoyable.
Re: With React 16.8, React Hooks are available in a stable release
#34Earlier quoted context omitted.
My impression is the community is mostly accepting, but some are taking a wait and see attitude until they can see it in production. 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.
Maybe it won't be an issue. However, it does go against regular advice of being explicit over magical. Depending on call order is something that immediately pops out as fishy. As always, programming is about trade-offs and the React team is claiming this trade-off is worth it.
Apparently React's internals have been doing similar order-based magic for a while already.
Re: With React 16.8, React Hooks are available in a stable release
#35Earlier quoted context omitted.
Maybe it won't be an issue. However, it does go against regular advice of being explicit over magical. Depending on call order is something that immediately pops out as fishy. As always, programming is about trade-offs and the React team is claiming this trade-off is worth it.
Apparently React's internals have been doing similar order-based magic for a while already.
That's also the reason why you have to make sure you're passing an update function to `setState` sometimes.
Re: With React 16.8, React Hooks are available in a stable release
#36Are hooks being accepted as a good design by the community? 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.
I'm using them on my current app, and have no intention of going back to classes.
> 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.
Re: With React 16.8, React Hooks are available in a stable release
#37Are hooks being accepted as a good design by the community? 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.
This post by React dev lead Dan Abramov goes deep into this question (much more detail than is available in the React Hooks FAQ or the ReactConf talks). https://overreacted.io/why-do-hooks-rely-on-call-order/
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.
Re: With React 16.8, React Hooks are available in a stable release
#38Are hooks being accepted as a good design by the community? 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.
Think of series of `useXXX` as declarations, not function calls, then everything will make sense to you.
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 setFlag(!flag)>{flag}
}
Component ToggleButton
// declarations
hasState: "flag" setterName: "setFlag"
hasState: "count" setterName: "setCount"
onEffect() { .... }
render() {
return setFlag(!flag)>{flag}
}
}
Re: With React 16.8, React Hooks are available in a stable release
#39Earlier quoted context omitted.
My impression is the community is mostly accepting, but some are taking a wait and see attitude until they can see it in production. 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.
Maybe it won't be an issue. However, it does go against regular advice of being explicit over magical. Depending on call order is something that immediately pops out as fishy. As always, programming is about trade-offs and the React team is claiming this trade-off is worth it.
If you have a stack machine, when you write a function like this.
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.
Re: With React 16.8, React Hooks are available in a stable release
#40I don't get it. I thought the main appeal of functions were that they were stateless so you had immutability. We already have classes if we want state, so why is this an improvement? Functions have slightly less overhead maybe? But then why didn't the React team just work on making classes have less overhead? It seems sort of "extra".
It's no longer about function. It's a component that happens to use `function` as an implementation detail.