Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A Critique of React Hooks

dillonshook.com

Post reply on HN
Print view View original

201–210 of 298 posts

Re: A Critique of React Hooks

#201

Post by andrewingram »

Saaster wrote: post #38

I feel that with class components I have a really good understanding of what is rendering and most importantly, when. componentDidMount, shouldComponentUpdate, PureComponent, etc. With hooks, it's much more magic. And clarity of rendering is literally the one thing I want from React. We have two projects, one using class components and one using hooks, and working on the class components one is unexciting, straightfo…

It's a bit of a trope by now, but there is a lot of truth in the common argument that if converting your class component to hooks makes it feel more complicated, you probably had subtle bugs in your class component -- usually an edge case you hadn't bothered to handle. The main quirk of hooks is that it makes problems in your components a lot more visible. I don't view this as a bad thing, but I totally get that it's frustrating.

Re: A Critique of React Hooks

#202

Post by ng12 »

kin wrote: post #195
ng12 wrote: post #192

Earlier quoted context omitted.

I don't really understand this. Can you explain how hooks relate to dynamic scoping?

Basically every call of a functional component MyComponent() represents a new scope. When you're working with a hook such as useEffect(), you have to pay attention to the dynamic scope so and correctly trigger the useEffect() with the dependency array.

But everything in that dependency array is from lexical scope, correct? Your hooks execute in the scope of that call to MyComponent().

Re: A Critique of React Hooks

#203

Post by acemarke »

waddlesworth wrote: post #187

I've read about Hooks for awhile, but they still confuse me. Maybe it's largely because I haven't experienced any of the pain points that are described as the motivation for their development, but I've used a number of state-management libraries that handle state. Just as one example, in a lot of posts and commentary I've seen, is that hooks are replacements for both HoCs and render props. Admittedly, I haven't yet t…

Hooks solve a couple different problems:

- Giving function components the ability to have internal state and trigger side effects, giving them the same capabilities as class components have had

- Reusing logic across components

I talked about the progress from mixins to HOCs to render props to hooks in a talk at ReactBoston last year [0], which had an example of tracking mouse coordinates using all four approaches. In that sense, yes, they do replace the other techniques as a way to reuse logic.

You call them inside of your function components, like this:

    function MyComponent() {
        const [counter, setCounter] = useState(0);
        const {x, y} = useMousePosition();

        // rest of the rendering logic here
    }
[0] https://blog.isquaredsoftware.com/2019/09/presentation-hooks...

Re: A Critique of React Hooks

#204

Post by kansface »

JMTQp8lwXL wrote: post #180
kansface wrote: post #163

Earlier quoted context omitted.

= React.createElement(Foo, { bar: "baz" })

I don't understand how people claim this is hiding huge levels of complexity. It's trivial syntactic sugar. If stylistically, you don't like it, oppose it on those grounds. But complexity? It is syntactic sugar for a function call.

I agree with you - so much so that I don’t use source maps to debug stuff. It’s also the same reason I strongly dislike hooks (they aren’t really JS) while at the same time, they solve a problem I very rarely have (shared behavior without shared state).

Re: A Critique of React Hooks

#205

Post by baron816 »

cageface wrote: post #188
desc wrote: post #156

I'm going to express something a lot of people are thinking and are being far too diplomatic about. React Hooks are a fucking stupid idea and always were. They're basically just adding dynamic scoping to a language and framework which doesn't need it, in one of the most 'magical' and confusing ways possible. You have to care about execution order to understand exactly how they'll all work and that will bite you event…

Hooks are an elegant & clever idea but they can be difficult to use in practice. You really need to understand in detail how closures work. Manually managing your dependency graph and memoizing in all the right places is harder than the old class-based model in my experience. I've really enjoyed working with React but it seems to me like some of the newer frameworks like Svelte have taken the best ideas from React wi…

> Manually managing your dependency graph and memoizing in all the right places

I wouldn't say it's harder, but it's certainly not simple. There are a handful of mistakes that I see repeated, but if you get over those hurdles, you can significantly simplify your components 99% of the time. It was very easy to have huge componentDidMount and componentDidUpdate methods in class components, and with logic scatter shot across a big file without the ability to easily reuse bits of it.

Re: A Critique of React Hooks

#206

Post by pcr910303 »

throwanem wrote: post #58
deckard1 wrote: post #42

Hooks elucidate everything I've felt wrong about React, but have not been able to put my finger on it until recently. Hooks reveal two major things with React: 1) React developers did not understand the component paradigm that they originally went with. If they did, then they would understand how silly it is that components cannot reuse logic. This was an entire debate many years ago. Composition vs. inheritance. You…

Who says functions don't have state? Referential transparency requires no such constraint; it only requires that state not leak into or out of a pure function save through its arguments (inward) and return value (outward). Beyond that, what they do within the space of their own lexical scope and the lifetime of their call stack frame is entirely their own business. I'm familiar with dynamic scoping via Emacs Lisp. I…

> it'd be surprising in any case to encounter dynamic scope in Javascript, a language which does not even support it.

Doesn't matter much, but just b.c. it's interesting: JavaScript actually does support limited dynamic scoping - `this` is scoped dynamically like in usual Lisps, and there's a with statement[0] that acts somewhat similar with `let` in Lisp.

[0] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

Re: A Critique of React Hooks

#207

Post by greatwhitenorth »

untog wrote: post #137
stevebmark wrote: post #136

Hooks have unlocked so much power in React but still deserve critiquing. However I think the author only hinted at the major complaint I have about hooks, which is that it's no longer Javascript. It's not a function, it's sort of like type system magic. Hooks can't be nested, order matters, can't be conditionally called, and you have to understand trickier memoization to avoid bugs. It also isn't portable knowledge t…

> React is great because it's vanilla Javascript What about JSX? It’s very useful but it’s also an absolutely huge departure from vanilla JavaScript and hides a fair amount of complexity behind what your code is actually doing.

JSX is 99% map/filter and boolean expressions. It's written between curly braces to be evaluated as a JavaScript expression. I don't understand how it's different from regular JavaScript.

Re: A Critique of React Hooks

#208

Post by Toine »

Saaster wrote: post #38

I feel that with class components I have a really good understanding of what is rendering and most importantly, when. componentDidMount, shouldComponentUpdate, PureComponent, etc. With hooks, it's much more magic. And clarity of rendering is literally the one thing I want from React. We have two projects, one using class components and one using hooks, and working on the class components one is unexciting, straightfo…

You have my vote for the best criticism of hooks in comments.

Re: A Critique of React Hooks

#209

Post by charrondev »

jiofih wrote: post #82
dgritsko wrote: post #61

Earlier quoted context omitted.

You could easily wind up with an infinite loop without hooks (for example, by calling `setState` in `componentDidUpdate`).

That would be trivial to spot. Not the case with hooks.

This is definitely not the case. I’ve seen enough class components with complicated componentDidUpdate methods. The method would then be broken up into multiple other smaller methods (or to re-use some logic in didMount and didUpdate)

A few iterations later and you have setState peppered throughout your component.

More often then not though I’ve seen a lot of class components that would just fail to update when certain props change. It’s much harder to miss these cases with hooks.

Re: A Critique of React Hooks

#210

Post by afranchuk »

I've been out of the React game for a while, and this is the first I've read about Hooks (or at least the first time I read enough to look into them). If I understand things correctly, they are automatic dependency tracking functions that will rerun as needed? Kinda like S.js [1]? Though that's different in that it's built around only that functionality, not integrated into a larger system.

[1]: https://github.com/adamhaile/S

Post reply on HN