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

121–130 of 298 posts

Re: A Critique of React Hooks

#121

Post by mrozbarry »

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 matter?

I'm sure looking at the code will cause a "oh, I get it" moment, but that doesn't mean it's obvious to anyone just picking up hooks.

Honestly, I think hooks are fine, but I'd almost prefer a signature like `const MyComponent = (props, { ...hooksHere })` so there's at least a false affinity between the application and the component.

Re: A Critique of React Hooks

#122

Post by kiliancs »

lhorie wrote: post #91
kiliancs wrote: post #84

Earlier quoted context omitted.

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…

> Was it sold as "just a view library" from official sources? Yes, the "V in MVC" term came straight out its main page: > JUST THE UI > Lots of people use React as the V in MVC. Since React makes no assumptions about the rest of your technology stack, it's easy to try it out on a small feature in an existing project. https://web.archive.org/web/20140321012426/http://facebook.g...

Thanks for finding that! Yes, it seems like this way of seeling it could cause false expectations. It is still true, though, that "React makes no assumptions about the rest of your technology stack, it's easy to try it out on a small feature in an existing project".

Re: A Critique of React Hooks

#123

Post by gotofritz »

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…

> hooks don't have an obvious context.

I mean, that's the whole point of hooks... they get the context of whatever host function scope they are in. That's why the 'reusable logic' spiel. So if you create a useLocalStorage hook, for example, you can then plug it into any function component and it will use. It's as if each function was an invisible class, with an invisible this.state

Re: A Critique of React Hooks

#124

Post by gotofritz »

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…

> It'll be interesting to see if whoever steps up to maintain React at that point will be able to grok its internal complexity, and to see how the community reacts to a rift when their favorite view library team pushes for one vision but the moved-on "rockstar facebook engineer" pushes for a different vision.

Kind of what is going on with Node / Deno... and like the chap who quit the Angular 2 team to start Aurelia hoped would happen to him (sorry buddy!). My guess is that he'll find out that there is more to a framework than rockstar developers. Like Facebook backing, or like UX designers being in love with your library because it reflects their approach to problem solving. Like CRA, hot module reloading and all that jazz. These are all things that put React where it is today

Re: A Critique of React Hooks

#125

Post by lioeters »

psmyrdek wrote: post #46

There's yet another valuable hooks critique that I recommend you to read - https://typeofweb.com/wady-react-hooks/ (Use Google Translate to convert Polish to English)

Hahah, this is good.

> React, like socialism, perfectly solves the problems that it created.

Re: A Critique of React Hooks

#127

Post by city41 »

jiofih wrote: post #77
city41 wrote: post #34

Earlier quoted context omitted.

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.

True, although I did mean my comment in the context of React. Hooks are basically them rolling back this choice.

Re: A Critique of React Hooks

#128

Post by ericmcer »

Feels like the author is someone who really sunk into the composed higher order component style of writing React. As someone who has coworkers who loved spreading logic into 'composable HoC' that only end up being reused 1-2x, I welcome hooks.

A single component wrapped by 3-4 HoC that each do trivial tasks always felt like mental strain rather than a helpful abstraction. My favorite was HoC's that added class component functionality to function components... just use a class.

Re: A Critique of React Hooks

#129

Post by andrewrothman »

Good critique. I agree about control flow and memoization. I tend to run into issues every now and then with memoization and hook "dependencies", but I'm getting better at it.

I think 1, 2 and 3 aren't really great arguments. There's always more to learn, and it seems that class components are on the way out, and are around mostly due to backwards compatibility. But it is true that a lot of legacy code uses them. I wish they'd have started with functional components, but I can't blame the team for not figuring out all of the details in advance.

I'm curious what others think. Thanks!

Re: A Critique of React Hooks

#130

Post by throwaway286 »

Saaster wrote: post #38

I feel that with class components I have a really good understanding of what is rendering and most importantly, when. componentDidMount, shouldComponentUpdate, PureComponent, etc. With hooks, it's much more magic. And clarity of rendering is literally the one thing I want from React. We have two projects, one using class components and one using hooks, and working on the class components one is unexciting, straightfo…

This is how I feel too, and I'm a confused how the reaction to hooks is so overwhelmingly positive. I find it quite strange that we need to set up an eslint rule to make sure our function arguments are correct, and it will automatically fill them out if we don't. And I need to memoize so many things! I feel like I'm not even writing javascript anymore.
Post reply on HN