A Critique of React Hooks • Hacker News Board

Re: A Critique of React Hooks

#161

Post by desc » Mon, Apr 27, 2020, 10:54 PM UTC

Gehinnn wrote: post #158

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…

Yes. Except mobx ;) I like to use function components together with class based observable view models. Only a single hook wires them up. Works like a charm and avoids all the IMHO confusing hook complexity.

Hmm, so the reusable bit is the straightforward inject-everything component, driven by an app-specific, app-aware hook-using part?

I can see how that can work for simple cases. Nesting components is going to get tricky though if the classes don't operate exactly the way the hooks expect.

Of course that's the problem: someone built hooks for their trivial cases and now they're the 'preferred' approach...

Edit: To clarify, 'simple' is going to be context-dependent since hook behaviour is. If your 'driving skeleton' of hook-based components is in the direct uninterrupted ancestry chain of every class component, you're probably using hooks in a near-ideal case.

Re: A Critique of React Hooks

#162

Post by iainmerrick » Mon, Apr 27, 2020, 11:03 PM UTC

ng12 wrote: post #66

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…

> But it should suffice to say, FUNCTIONS DO NOT HAVE STATE It's funny you say that: useState is the same model functional languages use to handle mutability. https://docs.racket-lang.org/reference/boxes.html

I think this is mostly a disagreement around terminology.

The GP is referring to purely functional languages like Haskell, where functions don’t have state and are referentially transparent. In Haskell, useState would have to use a monad.

Racket (and Lisp in general) has mutable state so doesn’t guarantee referential transparency. You can definitely write pure functions, and that’s good style in many contexts, but it’s not required or enforced.

I personally agree with the GP, and assume “functional programming” to mean pure functional programming. It’s common to use an FP style in non-pure languages, but I think this is FP if and only if you completely avoid state.

Re: A Critique of React Hooks

#163

Post by kansface » Mon, Apr 27, 2020, 11:05 PM UTC

sibeliuss wrote: post #159

untog wrote: post #137

Earlier quoted context omitted.

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

= Foo({ bar: "baz" })

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

Re: A Critique of React Hooks

#164

Post by acemarke » Mon, Apr 27, 2020, 11:06 PM UTC

vosper wrote: post #139

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…

> I look back on all our HOCs and function as children and shudder compared to how easy it is with hooks. If by "function as children" you're referring to render props, personally I was really happy to see that short-lived fad die out. I don't think render props made things simpler. Now if we can admit we never needed Sagas just to do some data fetching maybe we can burn that stalled-out old bandwagon, too :D (Sagas…

I'm a Redux maintainer, and yes, I keep trying to tell people that 95% of Redux apps don't need sagas. They're a great power tool for those cases when you have truly complex async workflows, but they're complete overkill for basic data fetching behavior.

I wrote about why I chose thunks as the default in our Redux Toolkit package:

https://blog.isquaredsoftware.com/2020/02/blogged-answers-wh...

and our Style Guide docs page specifically recommends using thunks as a default:

https://redux.js.org/style-guide/style-guide#use-thunks-for-...

Re: A Critique of React Hooks

#165

Post by pier25 » Mon, Apr 27, 2020, 11:06 PM UTC

williamdclt wrote: post #132

pier25 wrote: post #117

Earlier quoted context omitted.

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

Disagree. I understand `this`, but I very, very rarely encounter situations where it doesn't mean the same thing as Java's `this`. When you work on a full-React codebase, it just doesn't really happen. We used to have weird `this` behaviour on event handlers, but arrow functions and hooks fixed this. Not saying it's good or bad, just an observation

Right, but without understanding this one doesn't really understand arrow functions either.

Re: A Critique of React Hooks

#166

Post by acemarke » Mon, Apr 27, 2020, 11:09 PM UTC

mrozbarry wrote: post #121

One thing that baffles me is that no one has brought up that hooks don't have an obvious context. For instance, if I have a single app and component, and use a hook, I understand that the hook and app have some sort of implicit connection. But what happens when I have two distinct react apps on a page - does that break the ordering that hooks require? How does a hook have any affinity to the app, or does that even ma…

The ordering question is literally just about how you call them within a single specific component. That component can then be used as many times as you want, in as many apps as you want.

In other words, this is not legal:

    const [stateA, setStateA] = useState(false);

    if(stateA) {
        const [stateB, setStateB] = useState(42);
    }

Call as many hooks as you want, in whatever sequence you want. Just make sure all the calls are at the top level of that function component, and that you don't somehow change the sequence of those from one render pass to the next.

As for how they work, React already has metadata that describes each component in the tree. There's a specific field in those metadata objects that gets used for tracking internal component state, and for function components, that field stores an array / linked list of the hook calls you've made and their last saved results.

See these resources for more explanations on how hooks are implemented:

https://github.com/markerikson/react-redux-links/blob/master...

Re: A Critique of React Hooks

#167

Post by aero142 » Mon, Apr 27, 2020, 11:11 PM UTC

wk_end wrote: post #109

twic wrote: 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.

There was a lot of discussion in the Crank thread. Essentially, concurrent mode is the primary goal.

https://news.ycombinator.com/item?id=22903967

Re: A Critique of React Hooks

#168

Post by dcre » Mon, Apr 27, 2020, 11:18 PM UTC

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…

The React team’s claim (see my other comment) has been that by using React at all, you are already fully bought into all this magic, it’s just harder to tell.

Re: A Critique of React Hooks

#169

Post by lhorie » Mon, Apr 27, 2020, 11:25 PM UTC

lucasmullens wrote: post #145

untog wrote: post #137

Earlier quoted context omitted.

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

> an absolutely huge departure from vanilla JavaScript Doesn't it just convert to React.createElement? I wouldn't call it absolutely huge.

"just convert" is in itself a huge departure from plain Javascript (in the sense that you now need a whole transpiler to get anything running at all, vs just running the source code as is)

Re: A Critique of React Hooks

#170

Post by aidos » Mon, Apr 27, 2020, 11:28 PM UTC

jonny_eh wrote: post #157

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…

I never understood what was wrong with class components anyways. What did Hooks bring that couldn't be done in an easier to understand way with class components?

Hooks allow for declarative behaviour that’s harder to model other ways. With hooks, something like declaring when an event listener should be in play becomes much cleaner. The alternatives with class components are messy.

The above criticism that you don’t get to have pure functional components anymore doesn’t really make sense to me - either you have some lingering state to deal with, or you write a pure function. Your hand is forced by the problem. You could switch over to class components but they’re really not much clearer to read.

Most of the bugs I’ve seen have been around JavaScript’s crummy equality checks and the need for more memoisation.