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

111–120 of 298 posts

Re: A Critique of React Hooks

#111

Post by runawaybottle »

pacala wrote: post #105
viklove wrote: post #101

Earlier quoted context omitted.

> In the long term, change wins. Or else we'd be programming in JS1995. Change for the sake of change is not a sound argument. The thing about hooks is they don't enable a single thing we couldn't already do with HOCs. They are also much harder to read, because stateful logic is now just sprinkled around your render method rather than being isolated to places you know to look for it. I won't be using hooks ever, as f…

Of course. * "A Critique of React Hooks" * "A Critique of the Change Costs Induced by React Hooks". Objections to React Hooks are stronger if they don't invoke change costs as the primary three concerns.

He/she gave a very valid critique of state being jammed into your render method, vs state being handled in a predictable pattern in Class components.

And lastly, let’s not minimize change-cost. In the real world, it’s a cost. We’re all willing to pay it if it’s necessary, or affordable, but not because someone showed up and said ‘change please’.

Re: A Critique of React Hooks

#113

Post by karatestomp »

sebringj wrote: post #21

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 confusi…

They behave like class property & method declarations. But scattered about in a function and looked up by order rather than name. This is exciting and not considered redundant and obviously a bad idea, for some reason.

Re: A Critique of React Hooks

#114

Post by dcre »

traderjane wrote: post #60
dcre wrote: post #28

An 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-organ…

> A stateful function with effects. Your language just doesn’t have a primitive to express it. I wonder what about generator functions?

I don't see how generators would change anything here. "with effects", "stateful", and the integration between the two are all equally important in the statement.

Re: A Critique of React Hooks

#115

Post by pacala »

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…

Memoization is getting me too. I end up memoizing everything, which is more verbose than I'd like. Perhaps we're missing some obvious pattern?

Re: A Critique of React Hooks

#116

Post by pier25 »

pacala wrote: post #87
jiofih wrote: post #71

Earlier quoted context omitted.

You didn’t actually counter any of the authors’ points. This wonderful functional declarative pipe method of building UI applications where things are built using a straight-line series of composed functional transformations can really suck in real world applications as he tries to demonstrate. Anyone building with hooks now can relate to hooks bringing disorder to the codebase. Has your experience been different? Ho…

1. It's not more stuff to learn, it's different stuff to learn, arguably less. Learning Components is not a prerequisite for learning Hooks. Or perhaps I missed the memo, as I've built an app using Hooks, and still haven't need to learn what 'componentWillMount' is supposed to do. 2. Don't mix Components and Hooks. 3. Agreed, change is hard. It's also the only way to avoid stagnation. In the long term, change wins. O…

> In the long term, change wins

Yes, but how long is long term?

jQuery hasn't radically changed its methodology in almost 15 years.

Re: A Critique of React Hooks

#117

Post by pier25 »

petilon wrote: post #96
genezeta wrote: post #25

Earlier quoted context omitted.

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...

I am far more confused by hooks than by classes and 'this'.

Also you can't really try to protect JavaScript developers from understanding this. It's a fundamental part of the language.

Re: A Critique of React Hooks

#118

Post by ng12 »

sibeliuss wrote: post #102
s-km wrote: post #73

Earlier quoted context omitted.

>It's unreal that in React I have to deal with occasional infinite loops now because of hooks. Sure, React catches the loop cycle so things don't totally freeze but I don't recall ever having to deal with this before them ... missing dependency accidents requiring linters to prevent Infinite loops and missing dependencies are/were issues with `componentDidUpdate`/`componentWillUpdate` and `componentDidMount` as well,…

Reference issues: 1) Needing an advanced understanding of closures. Not always, but sometimes. That "sometimes" is often unintuitive, requiring weird solutions like useRef. Good luck beginners. 2) Things like updating reducer state by using a spread object, which creates a new object which can then send a system haywire. Seems fine, and is mostly fine in most cases, but hey, oftentimes not fine, and why that's so is…

> Things like updating reducer state by using a spread object, which creates a new object which can then send a system haywire

This is what you should be doing and not doing this seems more likely to cause problems. Do you have an example?

Re: A Critique of React Hooks

#119

Post by lhorie »

azhu wrote: post #15

All of this reads akin to someone criticizing an apple for not being an orange. Every point is an intentional design decision. Learning new things is necessary, leaving class syntax behind was a choice, and imposing limits on (controlling) application design is the point of libraries. The team is pushing a functional declarative pipe method of building UI applications where things are built using a straight-line seri…

> imposing limits on (controlling) application design is the point of libraries

That's the point of _frameworks_. It's very ironic to see this being said in defense of React, given that its original appeal was precisely the opposite stance (i.e. React was "only the v in mvc", in response to the notion that frameworks of the time were imposing).

Re: A Critique of React Hooks

#120

Post by acemarke »

Scarbutt wrote: post #108
pacala wrote: post #87

Earlier quoted context omitted.

1. It's not more stuff to learn, it's different stuff to learn, arguably less. Learning Components is not a prerequisite for learning Hooks. Or perhaps I missed the memo, as I've built an app using Hooks, and still haven't need to learn what 'componentWillMount' is supposed to do. 2. Don't mix Components and Hooks. 3. Agreed, change is hard. It's also the only way to avoid stagnation. In the long term, change wins. O…

Unless you learnt react from non-official sources, you can't avoid learning components because they teach them first.

The React team is working on rewriting the docs to focus on function components and hooks first, as of this quarter:

https://www.reddit.com/r/reactjs/comments/g2pda4/functional_...

Post reply on HN