Live data from Hacker News

A Critique of React Hooks

dillonshook.com

101–110 of 298 posts

Re: A Critique of React Hooks

#101
post #87
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. 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 far as I'm concerned.

Re: A Critique of React Hooks

#102
post #73

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…

>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 not always clear. So then there's memoization, and useCallback and all of these safety checks -- each with their own dependencies array that need to be checked. It's really too much tbh. There are lots of solutions out there that use proxies to check this stuff; React should have baked that into the core and completely removed that responsibility from the user unless they wanted to opt-in micromanage performance of their code.

Re: A Critique of React Hooks

#103
post #69

The universe is stateful; no matter how hard FP zealots try to abstract that out of code, they will never change this fundamental fact.

The universe is also highly concurrent and probabilistic, but that doesn't mean we need to design our programming languages that way.

Re: A Critique of React Hooks

#104
post #95
post #4

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

But that took the simplicity away. Everyone that knows modern JavaScript knows classes. Now they have to learn this alien concept called "hooks". Now regarding reusability: I have been doing UI code for many many years and I have rarely felt that logic inside UI components need to be reusable. First move all business logic out of UI components into model-layer objects. This eliminates most of the need for reusable lo…

You're only calling it not simple because you're not familiar with it. I personally think hooks are simpler despite being different. Everyone knows "classes" but React's usage of them is not typical and there _are_ non-standard behaviors about using them that you have to learn when learning React (because the classes necessarily exist within the React runtime). Either way you're dealing with React.

And on a day-to-day basis for me, there are still plenty of uses for reusable logic inside of components even after extracting business logic / creating small focused components, especially as it pertains to presentation. A simple example that I use somewhat frequently is a window-size watcher.. a pretty simple hook that watches the window-size, re-renders when it changes (on a debounce), and it provides the current width x height of the window, allowing the component to use those values to calculate some view parameters. With hooks, it's as simple as plopping `const { windowHeight, windowWidth } = useWindowSize()`. Without hooks it generally requires wrapping a component with another.

I've been using hooks basically since they came out and IMO they're way more in tune with React's programming model than class-based components. Even if you create custom hooks for most components, the paradigm still encourages developers to encapsulate related pieces of component logic into their own hook-functions rather than spreading that logic across multiple lifecycle methods. I haven't come across a single situation where I would have preferred a class based component.

Re: A Critique of React Hooks

#105
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…

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

Re: A Critique of React Hooks

#106
post #69

The universe is stateful; no matter how hard FP zealots try to abstract that out of code, they will never change this fundamental fact.

Nonsense. These are all just techniques for modeling reality, not reality itself.

You could model the universe just as accurately as a stateless function of time as you could as a stateful entity that moves through time.

Re: A Critique of React Hooks

#107
post #57

ClojureScript user here, with a big SaaS app using React, developed over the last 4 years or so, using the excellent Rum library, https://github.com/tonsky/rum . It seems to me that React Hooks, like so many things in the JavaScript world, solve a problem I do not have. To this day, despite being a heavy user of React, I don't even fully know what they do. I've read the "Motivation" section of the React Hooks Intro,…

Yeah, that's why rum recently added support for hooks...

Re: A Critique of React Hooks

#108
post #87
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…

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

Re: A Critique of React Hooks

#109
post #29

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

This is really compelling - thanks for linking it. Is there a downside here? Has React responded at all? I don’t hate hooks, but using async + generators like this looks so obviously better and more intuitive here; like such a clearly great, simple idea that I’m embarrassed I didn’t ever think of it myself.

Re: A Critique of React Hooks

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

You'd be surprised. The only deeper dive into Components is https://reactjs.org/docs/state-and-lifecycle.html of the "Main Concepts" section, which I skipped in favor of https://reactjs.org/docs/hooks-state.html of the "Hooks" section. Haven't got to "Advanced" yet, hope to stay clear of that.
Post reply on HN