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

71–80 of 298 posts

Re: A Critique of React Hooks

#71

Post by jiofih »

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? How did you avoid the pitfalls mentioned?

Re: A Critique of React Hooks

#72

Post by jtdev »

zodiac wrote: post #20

I personally don't use hooks (or functional components) at all, but recently read this post from Dan Abramov about algebraic effects which makes a point (among others) the hook mechanism is a pretty simple way to implement state/effects/context in a language with algebraic effects. https://overreacted.io/algebraic-effects-for-the-rest-of-us/

Yay, just what we all needed to help us write clean, maintainable code... algebraic effects??

Re: A Critique of React Hooks

#73

Post by s-km »

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…

>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, though. On the plus side, you now have a linter which can both point out these errors and automatically fix them for you. I agree that the whole thing is a bit leaky and dumb though, but there's no way to fix that without introducing some sort of compilation/optimization step and afaik the React guys aren't really considering that at the moment.

>Weird, unexpected reference issues

Not sure I've run into this before. Do you have any examples?

>strange programming patterns, a team member having to write a terrifying novel

The first bit seems like personal preference or something, not sure what you're referring to as strange. The `useEffect` novel exists because a ton of people had built up their (incorrect) mental model of how React works with lifecycle methods and were making mistakes or running into unexpected behaviour because they assumed `useEffect` was the exact same thing as `componentDidMount`.

Re: A Critique of React Hooks

#74

Post by frosted-flakes »

abuldauskas wrote: post #56
frosted-flakes wrote: post #40

Earlier quoted context omitted.

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.

Oh, I thought you meant that the hooks would be called there, which was one of the many alternative proposals made after hooks were announced.

In any case, it still wouldn't work because hooks are composable. You can create your own custom hooks outside of components which can be used as if it was one of the primitive hooks. That's not possible if the primitive hooks can't be accessed outside the component scope, unless they're passed in as parameters every time the custom hook is called (and that would be a right pain in the backside).

Re: A Critique of React Hooks

#75

Post by gregkerzhner »

a-priori wrote: post #62

I've been using hooks full-time for the last year or so in a _very large_ React code base (one of the largest in the world). None of these so-called problems are real in my experience. The first point is just whining about not wanting to learn new things -- we've on-boarded many new people onto our team in this time, and hook-based code is the easiest to understand. It's the old class-based components that are hard,…

In my experience people abuse react components by making them too big with too much functionality. If you have a bunch of hooks tied together in a brittle way, thats not the hooks's fault. It's a good sign that you need to refactor your component into smaller sub components or move functionality out of components all together into redux or some other non UI related code. A big component with lots of logic will always be a liability whether it's hooks or classes because it will mix presentation with business logic and will rarely be well tested.

Re: A Critique of React Hooks

#76

Post by ng12 »

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…

Well #2 isn't really a pitfall, for starters. I have a new feature that solved a problem I had but I can't use it in the code I wrote before I had it without refactoring? I don't think that critique really has anything to do with Hooks, just software development. It's also basically a rephrasing of #3.

Re: A Critique of React Hooks

#77

Post by jiofih »

city41 wrote: post #34
tenaciousDaniel wrote: post #3

IMO, we've traded the complexity of `this` with the complexity of hooks. Maybe I'm weird, but I never really wrote JS that caused scoping issues, so I never found `this` to be a problem. At the very least it's a complexity that is internal to the language itself. Hooks just feel so weird and alien to JS. I find them very, very difficult to reason about. - difficult to reason about except for a few simple use cases .…

A big problem with `this` is it is mutable. Dan Abramov has a nice article[1] explaining why that is a problem and how it leads to subtle bugs that are common in React apps. Hooks eliminate this problem, and I would guess this was one reason they decided to move forward with them. [1] https://overreacted.io/how-are-function-components-different...

That’s not a problem with “this”, but a self-inflicted problem from React’s chosen model of reusing class instances. It’s a design choice made by them and not a language issue at all.

Re: A Critique of React Hooks

#78

Post by tenaciousDaniel »

brlewis wrote: post #36
tenaciousDaniel wrote: post #3

IMO, we've traded the complexity of `this` with the complexity of hooks. Maybe I'm weird, but I never really wrote JS that caused scoping issues, so I never found `this` to be a problem. At the very least it's a complexity that is internal to the language itself. Hooks just feel so weird and alien to JS. I find them very, very difficult to reason about. - difficult to reason about except for a few simple use cases .…

> Maybe I'm weird, but I never really wrote JS that caused scoping issues, so I never found `this` to be a problem Either you're weird, or you've been doing JS mostly in the modern era of fat arrow functions, and fat arrow functions have succeeded at reducing the confusion from nested functions each with their own `this`.

Even before arrow functions I just never had much trouble. I had a very consistent way of writing logic. Only ran into scoping issues a few times.

Re: A Critique of React Hooks

#79

Post by efdee »

runawaybottle wrote: post #33
efdee wrote: post #27

Earlier quoted context omitted.

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

But focusing in on the ‘this’ criticisms highlights the general criticisms. They think ‘this’, or the Class model is a barrier to entry for React. React is a great framework, and super intuitive on so many fronts, but where it misses, it misses big. To come to the conclusion that the Class model, a pretty predictable pattern, is more a barrier to entry, or a conduit for confusion, is really misguided. Just take a loo…

I agree that the lookup map thing looks like very bad advice. I can't see a reason why you'd do something like that.

On topic, it has been my understanding that the React team is moving away from classes for a number of reasons. Not just because it confuses people (although the pattern seems to create expectations that aren't met due to Javascript's weird 'this' behavior), but also because it doesn't have a good pattern for code reuse (as demonstrated by the lack of mixins that used to be popular in React's createClass syntax) and also because it seems to be a suboptimal pattern for compilers.

That said, I've moved on from class components to function components with hooks and I can't remember the last time I thought something would be easier to implement as a class component, even though it is still an option to do so. But that is, of course, anecdotal.

Re: A Critique of React Hooks

#80

Post by nightski »

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

FP does not do that.

First of all, there is stateful code and then there is effectful code. It sounds like you are talking about the second, not the first. You can have tons of state and remain mathematically pure.

Where people get hung up is effectful code, or mutable state. Even one of the more hardcore FP languages, Haskell, does not try to abstract that out. Instead it embraces it fully by giving constructs in the language to describe and control effects! This is far more powerful than straight up imperative languages. If anything, writing mutable, effectful code is more powerful in Haskell than in C/C++.

Where Haskell gets difficult is when writing effectful code that interacts with external C libraries and the OS. But this has nothing to do with purity, state, or effects. It really only has to do with the fact that it is designed to have lazy evaluation by default. Which itself has a lot of advantages, but it makes this interaction more difficult as code does not execute in the same order as you write it.

You may find that languages such as OCaml, which are fully functional and have strict evaluation are a joy to work with.

Post reply on HN