Live data from Hacker News

A Critique of React Hooks

dillonshook.com

51–60 of 298 posts

Re: A Critique of React Hooks

#51
post #16

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.

Agree, I don’t know what is going on there but it sure smells like something you shouldn’t need to do.

Re: A Critique of React Hooks

#52

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 Services that Angular is still on proves that there-are-solutions. There are solutions for reusing logic between classes. Thing that bothers me the most is not that there's something wrong with fixing your own issues, but the fact that developers outside React Core Team start to think that "well, you cannot reuse logic between components".

Re: A Critique of React Hooks

#53

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…

The "idea" that react hooks try to implement is very common in FP languages though. It has a lot of parallels with extensible effects; which is a pure, functional embedding of the idea of hooks

Re: A Critique of React Hooks

#54

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…

The problem before was that your class component was not updating correctly and rendering stale & out of sync data. If it were updating correctly, it would have had the same infinite loop problems.

Re: A Critique of React Hooks

#56

My only issue with Hooks has been that they are not inputs into the component. It's a step in the right direction of making React more functional I would just preferred less magic, personally. function Component(props, { useState, useContext }) { ... } Of course that would break backwards compatibility with the old 2nd argument being context, so I get why they did it.

That's not the only problem with your approach. It is extremely common to use the output of one hook in the input of another, and that's only possible if the hooks exist in the function body.

I don't really understand how this approach breaks what you are describing.

All I'm saying is that instead of hooks API being imported from React at global scope it could be provided as inputs into the components directly. They would still exist in the function body as you put it.

Re: A Critique of React Hooks

#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, and it seems that I have none of the problems they describe: I can (and do) easily add stateful logic via Rum mixins, and that logic is reusable across components. Also thanks to Rum mixins, complex logic is understandable and does not get all thrown into a single 'componentDidMount' function. As to "Classes confuse both people and machines", I find it hard to relate to this problem, because I don't really see any classes. I work with components that have a render function and mixins, and if you don't use any mixins, a component looks just like a function.

This tends to be a recurring theme: every once in a while I read an article about JavaScript and React, and I can't even relate to the problems, because they do not exist in my world. Another good example is hints on how to optimize apps to avoid excessive re-rendering, something I get for free with ClojureScript and immutable data structures (you can always quickly tell if two data structures are equal and avoid rendering).

Re: A Critique of React Hooks

#58

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 have yet to encounter anything like it in React, and it'd be surprising in any case to encounter dynamic scope in Javascript, a language which does not even support it. The closest I can come to understanding what you must mean here is to think you're very confused about how React props work, but that doesn't seem likely either - I can hardly imagine someone having such an evidently strongly held opinion about something, and having that opinion turn out to be based on a fundamental misunderstanding of the subject.

Would you mind explaining in some more detail the issues you see with React functional components? You mention having an essay's worth of material, and while that's probably more than we need to support a discussion, perhaps you'd be so good as to boil it down to a few points with a little more substance to them than "React developers don't know what they're doing" and "this is insane".

Re: A Critique of React Hooks

#59
post #27

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

That is about a lot more than just 'this' confusion though.

I was just providing the link.

Re: A Critique of React Hooks

#60
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?

Post reply on HN