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

81–90 of 298 posts

Re: A Critique of React Hooks

#81

Post by jiofih »

hombre_fatal wrote: post #47
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…

> they did not understand > they do not understand > This is insane This sort of post that asserts that nobody understood or put delicate thought into something is just pompous and lacks intellectual curiosity. At least respond to their rationale. In doing so, you’ll find that everything is just trade-offs. btw Dan Abramov is great to follow on twitter. He often responds to criticism and clarifies React decisions and…

It fares well next to all the other comments saying this article is “pure whining”.

Re: A Critique of React Hooks

#82

Post by jiofih »

dgritsko wrote: post #61
sibeliuss wrote: post #31

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. Weird, unexpected reference issues, missing dependency accidents requiring linters to prevent, strange programming patterns, a team member having to write a terrifying novel like https://overreacted…

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.

Re: A Critique of React Hooks

#83

Post by lhorie »

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?

Yep, there was even a library making the rounds recently that leverages them: https://crank.js.org/

Re: A Critique of React Hooks

#84

Post by kiliancs »

lhorie wrote: post #48
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…

It's interesting that the original appeal of React was that it was "just a view library", but now apparently it's more like a "language". It really shows the biases of the maintainers (the "just a library" thing being a philosophy I liked from vjeux, and the "language-likeness" being very obviously a heavy influence from sebmarkbage). The thing w/ "language-ness" (as opposed to "library-ness") is that additions and c…

Was it sold as "just a view library" from official sources?

I understand "just a view library" might have been used to contrast it to full framworks that dictate a lot more than React, but it's important to note that the key React feature compared to other view libraries is precisely that it's not "just a view library": state is at its core.

It's hard to disagree with the the pain of React having to leave the comfort of plain idiomatic JS to better fulfill its goal, but to me React's efforts are in a way an experiment to find some primitives that should be baked into JS engines to allow for these mature, fine tuned experiences without putting the burden on the library.

Re: A Critique of React Hooks

#85

Post by ng12 »

psmyrdek wrote: post #52
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…

RE: 1) "it is that components cannot reuse logic" - +1 to this - recently I re-watched original hooks talk by Dan Abramov and was not able to finish it with conclusion different than "you guys really fix issues you invented before". Class-based components and reusability of logic is something that existed years before React, and probably will exist years after React. Even this concept of Dependency Injection and Serv…

Angular does not have a solution for this as far as I know. It's not about re-using logic. It's about re-using reactive logic that ties in to your component's lifecycle.

Re: A Critique of React Hooks

#86

Post by jiofih »

luwes wrote: post #65

Hooks are nothing new, it's just repackaging of https://github.com/dominictarr/observable https://github.com/adamhaile/S Mobx and Vue use the same technique for running computeds. As does Solid and Sinuous, etc...

Hooks are much more a reimplementation of the component lifecycle; receiving a change stream is only one of the use cases and has very little resemblance to observables, except that they trigger a re-render “automatically”.

Re: A Critique of React Hooks

#87

Post by pacala »

jiofih wrote: post #71
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…

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. Or else we'd be programming in JS1995.

4. Insufficient example. What is the business case for a memoized hook returning hooks? Perhaps there is a simpler design, can't comment.

5. There is no global control flow. There is only per function component control flow, which proceeds from top to bottom. Possibly preempted by a hook/hookfn execution, if my early learning curve is to be believed. Which shouldn't matter if one is thinking in terms of 'pure functions returning jsx', as preempted functions do not return, thus have no observable effect.

Tip: Only change hook state from event handlers, never from render function code.

Re: A Critique of React Hooks

#88

Post by RedBeetDeadpool »

Is `more stuff to learn` seriously a critique? I mean if you want to stop learning stuff then maybe, go live in your own little bubble.

The other criticisms seem a little bit like someone who doesn't understand how hooks works criticizing how hooks work because he doesn't understand how hooks work. Perhaps, he doesn't understand how hooks work because he doesn't want to learn more stuff?

Re: A Critique of React Hooks

#89

Post by jiofih »

efdee wrote: post #16
runawaybottle wrote: post #9

A lot of times I just use a simple React class. The author’s lookup map to return a lookup of other hooks, yikes. A class component would probably solve that in a more predictable way. Don’t feel dirty for doing things simply. If your functional component has entire lookup maps for hooks, it’s probably too complicated as a standalone functional component to drop hooks in.

It's hard to reason about without an actual real-life use case, but the lookup thing he's doing looks extremely convoluted to me.

Once you start using Context everything has to become a hook to be able to consume it, I bet that’s what’s goin on there.

Re: A Critique of React Hooks

#90

Post by petilon »

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…

> how silly it is that components cannot reuse logic

It may be that your component is too complicated. Components should only have UI code. First move business logic out of the component, into your model layer, and make it reusable there. This step will eliminate most of the need to reuse logic in components. If you still have logic inside your component that you want to reuse consider restructuring your component into multiple simpler components.

Post reply on HN