My take away from hooks is that it is pushing toward making your components simpler. One of the gotchas of hooks is that it kind of "lies" in the way it looks. Take useRef or useState for example. These things are only defined one time even though the are declared in such a way to look like they are defined over and over again each render. They are actually key lookups under the hood. This was a main point of confusion for me initially and I'm sure I'll find out more that I assumed incorrectly as I go. Auto-magic sometimes is confusing to me.
A Critique of React Hooks
21–30 of 298 posts
Re: A Critique of React Hooks
#22Earlier quoted context omitted.
Hooks weren't invented because of 'this' complexity though, but rather as a better way to handle reuseable code (somewhat) akin to mixins.
I'll see if I can find the link, but I recall seeing some references in the official docs, naming `this` complexity as a key inspiration for looking to hooks as an alternative to stateful classes.
That complexity was largely avoided by using arrow functions.
Re: A Critique of React Hooks
#23React is great at rendering data. It should've stopped there.
Re: A Critique of React Hooks
#24I mean, I got full marks on the quiz in the article. I had to think about the code, but no more than if the same had been implemented as classes. I have been using React for a very long time though, but the areas where execution order can be confusing aren't a problem new to hooks.
One criticism of the article is that it seems to argue that you lose the ability to provide HOC (and probably render-prop) APIs if you adopt hooks in your library. But it's fairly easy to automatically turn those types of hooks into HOCs, so it actually makes sense to have the hooks API be the primary one. You can't really do it the other way around, i.e. turn a HOC into a hook.
Re: A Critique of React Hooks
#25Earlier quoted context omitted.
Hooks weren't invented because of 'this' complexity though, but rather as a better way to handle reuseable code (somewhat) akin to mixins.
I'll see if I can find the link, but I recall seeing some references in the official docs, naming `this` complexity as a key inspiration for looking to hooks as an alternative to stateful classes.
It's right there in their intro to hooks in the section "Classes confuse both people and machines" [0].
[0] https://reactjs.org/docs/hooks-intro.html#classes-confuse-bo...
Re: A Critique of React Hooks
#26The reaction to react hooks has been (as far as I've seen) a little too positive, so I was looking forward to read a genuine critique. However, I'm disappointed. In reverse order: > 5. They Complicate Control Flow A set of contrived examples, within which the only genuinely confusing part is not related to React at all. It's Javascript's object non-equality ({ multiplier: 5 } !== { multiplier: 5 }) > 4. The Rules of…
Agree, "More Stuff to Learn" isn't really a critique of hooks, it's a critique of learning .
Yeah, I don't really get this criticism in regards to hooks. I think it took me maybe an hour to learn them. That's basically nothing.
Re: A Critique of React Hooks
#27Earlier quoted context omitted.
I'll see if I can find the link, but I recall seeing some references in the official docs, naming `this` complexity as a key inspiration for looking to hooks as an alternative to stateful classes.
It's right there in their intro to hooks in the section "Classes confuse both people and machines" [0]. [0] https://reactjs.org/docs/hooks-intro.html#classes-confuse-bo...
That is about a lot more than just 'this' confusion though.
Re: A Critique of React Hooks
#28An important point I don't see being made in the article or the comments is that hooks are meant as a more faithful (or at least less misleading) representation of what was going on under the hood in React already.
The problem with the JS class representation is that people already understand what classes and instances are, and that leads to incorrect inferences about how React is working. In addition to better-organized code, the hooks abstraction is partly aimed at preventing people from making those wrong inferences. This also explains why they are uncomfortable compared to classes and functions — the point is that was a false comfort because those representations are misleading.
Dan Abramov calls hooks a "missing primitive":
"Why are these models insufficient to describe React? “Pure function” model doesn’t describe local state which is an essential React feature. “Class” model doesn’t explain pure-ish render, disawoving inheritance, lack of direct instantiation, and “receiving” props.
What is a component? Why do you start writing it one way and then have to convert into another way? Why is it “like A but also like B”? Because it’s neither. It’s a thing of its own. A stateful function with effects. Your language just doesn’t have a primitive to express it.
That’s what Hooks are. Those missing primitives. They are library-level but conceptually they are part of the “React language”. Hence the language-like “rules”.
They could be syntax. They would be in Eff or Koka. But the benefits are not worth the friction it creates in JS."
https://twitter.com/dan_abramov/status/1093696560280596491
Re: A Critique of React Hooks
#29I learned about Crank today:
https://crank.js.org/blog/introducing-crank
Crank itself is interesting, but what's relevant here is the broader critique of React there.
Re: A Critique of React Hooks
#30I have some similar gripes. I find Hooks to save a bit of coding overall. I've found my functional components to be about 10-20% smaller than my class components. I'm not 100% convinced it's really worth it, though. With class components, my state/props are clearly defined within the constructor and/or PropTypes. This makes it easy to understand the overall architecture of a component. Functional components with Hook…
Having a separate useEffect certainly scatters your code, but it helps prevents bugs that cause your states/effects to go out of sync.
If you use a callback on setState in order to listen for async state updates like
setState({ myState: 'newValue' }, () => { this.doSomething(); });