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.io/a-complete-guide-to-useeffect/ for something that was never really a problem before. The list goes on and on.
A Critique of React Hooks
31–40 of 298 posts
Re: A Critique of React Hooks
#32The reaction to react hooks has been (as far as I've seen) a little too positive, so I was looking forward to read a genuine critique. However, I'm disappointed. In reverse order: > 5. They Complicate Control Flow A set of contrived examples, within which the only genuinely confusing part is not related to React at all. It's Javascript's object non-equality ({ multiplier: 5 } !== { multiplier: 5 }) > 4. The Rules of…
I initially had a few, but after making sure they weren't just learning curve exasperations in disguise, I realized they all boil down to that they should've just started out with this and never had any class components.
I often see developers mix up classes and functional components with hooks in abominable ways, and every pitfall to hooks I can find just boils down to improperly brackish OO class model polluted thinking.
Re: A Critique of React Hooks
#33Earlier 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.
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 look how simple functional components can take on a quasi Class-like form with lookup maps for hooks in this particular article. When you advocate for stuff like this, you are injecting the community with effectively bad practices.
The React dev team can not resort to the ‘You probably don’t need ________’ article in perpetuity. At some point, they have to say to themselves - ‘We probably don’t need to add this to the API’.
Re: A Critique of React Hooks
#34IMO, 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...
Re: A Critique of React Hooks
#35Overall I think hooks are a fine addition to the React toolbox. But I think they are very easy to overuse and the complexity of hooks seems to increase exponentially. I've been involved in two code bases now where hooks are just everywhere and they were both an absolute nightmare. But I've also been involved in code bases where hooks are used more sparingly, about on par with when HoCs were used, and it's rather pleasant. In general, the more "dumb" components your app has, the more manageable it seems to be overall.
Re: A Critique of React Hooks
#36IMO, 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`.
Re: A Critique of React Hooks
#37I have some similar gripes. I find Hooks to save a bit of coding overall. I've found my functional components to be about 10-20% smaller than my class components. I'm not 100% convinced it's really worth it, though. With class components, my state/props are clearly defined within the constructor and/or PropTypes. This makes it easy to understand the overall architecture of a component. Functional components with Hook…
Components with lots of hooks in them remind me of spreadsheets. I find myself tracing from one hook dependency array to the next, trying to follow the logic.
Re: A Critique of React Hooks
#38I 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, straightforward, sometimes repetitious, but never confusing. When writing hooks on the other hand it's constant gotchas; can't do that here, didn't memoize this, can't call that within this, etc. fuzzing until it works as Reacts expects. And then the bloody thing still renders on every frame. Back to the drawing board to figure out the right magic incantation. Probably memoize a few more layers, ugh.
Re: A Critique of React Hooks
#39My 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 }) { ... }
Re: A Critique of React Hooks
#40My 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.