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

181–190 of 298 posts

Re: A Critique of React Hooks

#181

Post by JMTQp8lwXL »

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…

If you oppose JSX, then you should doubly oppose Angular Templating language, since that's an entire language construct that gets compiled to JS function calls. Broader point: We need some syntactic sugar on top of JavaScript for writing UIs. JSX is about as simplistic of an abstraction you can get it. It's incredibly easy to reason about its pre and post-compiled syntax. Not the case with other paradigms.

Re: A Critique of React Hooks

#182

Post by JMTQp8lwXL »

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

The problem with 'this' (well, one concern): sometimes you don't have a choice. Suppose you consume a library, where you call a function, passing a function as an argument. Your function's this context can be overwritten, even if you don't desire it to be. I recently ran into this issue when consuming a third party library.

Re: A Critique of React Hooks

#183

Post by JMTQp8lwXL »

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 the most legitimate criticism I've seen in the discussion. Hooks give you more control. 'useEffect' will only re-run when any value in the dependency array is updated. In class syntax, you have 'componentDidUpdate', but that function gets called after any prop or state change. With hooks, there is more granularity. Personally, I've found reasoning about hooks to be a learning curve that was conquerable in about a week. But there is no arguing, it requires you to mentally reason a little bit further than the blunt 'componentDidUpdate'.

Re: A Critique of React Hooks

#184

Post by hajile »

frank_nitti wrote: post #146
lucasmullens wrote: post #145

Earlier quoted context omitted.

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

By this logic, what could ever be considered "huge" departure? Any new language construct "converts" to something lower level unless that language is a set of assembly instructions. I mean, Elm converts to vanilla JS but few would say it's a small departure from it.

That's just reductio ad absurdum claim.

JSX is one simple conversion while coffeescript or elm are entire turing-complete languages. It's like claiming a smiley face on the back of a receipt is no different from the Mona Lisa.

Re: A Critique of React Hooks

#185

Post by lhorie »

dgritsko wrote: post #17
lucideer wrote: post #10

The 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…

Agree, "More Stuff to Learn" isn't really a critique of hooks, it's a critique of learning .

TFA addresses this: it qualifies by saying learning is good as long as it's useful outside of whatever narrow scope they appear. The real criticism in that section is that hooks (and e.g. gotchas related to things like useEffect, stale closures, etc) are non-transferrable knowledge.

Re: A Critique of React Hooks

#186

Post by abacadaba »

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…

+1 for being on board with whatever killed render props and a bunch of HOC's.

Mostly like them, but still not sure the canonical way to write update logic comparing prevProps to current props and running something if it changed where there is more than one dependency though. Need to store prev value in state to compare, or best to ignore the exhaustive deps warning and only run when the prop in question changes? Swear I looked all over and couldn't find a good answer.

Re: A Critique of React Hooks

#187

Post by waddlesworth »

I've read about Hooks for awhile, but they still confuse me. Maybe it's largely because I haven't experienced any of the pain points that are described as the motivation for their development, but I've used a number of state-management libraries that handle state.

Just as one example, in a lot of posts and commentary I've seen, is that hooks are replacements for both HoCs and render props.

Admittedly, I haven't yet tried to do any actual development with hooks, but I can't even figure out how to solve the problem in the example in docs for HoCs[0].

Do you pass in a hook as a prop? That doesn't seem wise. A custom hook for each data source still has the same code duplication.

The docs talk a lot about how to build individual components using hooks, but very little about tying them together.

[0]: https://reactjs.org/docs/higher-order-components.html

Re: A Critique of React Hooks

#188

Post by cageface »

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…

Hooks are an elegant & clever idea but they can be difficult to use in practice. You really need to understand in detail how closures work. Manually managing your dependency graph and memoizing in all the right places is harder than the old class-based model in my experience.

I've really enjoyed working with React but it seems to me like some of the newer frameworks like Svelte have taken the best ideas from React without the baggage.

Re: A Critique of React Hooks

#189

Post by lilactown »

iLemming wrote: post #150
onion2k wrote: post #68

Earlier quoted context omitted.

You've solved the problem that hooks solve by using Rum mixins instead, and you're confused why you don't need hooks?

Have you actually used Clojurescript with React? Just any cljs library - Reagent, Rum, Re-frame, Fulcro? Maybe try it, perhaps then you'd understand why Clojure developers often get confused what problems every new hype cycle in JS/TS world is trying to solve. Because Clojure idioms often nicely turn them into something you don't have to worry about at all.

I use ClojureScript professionally, and I believe Hooks are great. Reagent, Re-frame all have tradeoffs that they've made to try and shoe-horn in a solution that Hooks cleanly provides first-class support for.

I see a lot of other Clojure users wade into discussions like these and reveal an unexamined view of the technology they use and the way that other communities are trying to solve these same problems. It's really discouraging to see people put Clojure(Script) and associated libs on a pedestal, because it removes any nuance from the discussion and makes people think that the Clojure community are a bunch of holier-than-thou zealots.

FWIW, I was (am still) super excited about Hooks and have posted a lot of things critiquing ClojureScript React wrappers in the past, but I recognize now that they are making tradeoffs that ultimately are what the authors think are in the best interest of their user base. It would really be great if you (and everyone else) would enter these discussions with the same assumption.

Re: A Critique of React Hooks

#190

Post by cageface »

acemarke wrote: post #164
vosper wrote: post #139

Earlier quoted context omitted.

> 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 doc…

I had to rescue a codebase that was all-in on sagas by developers that didn't seem to really understand what they were for. It was one of the most difficult and frustrating projects I've ever worked on. Debugging was a total nightmare because bugs were so decoupled from their causes. I'm sure there are cases where, in the right hands, sagas can help solve complex problems but, like redux, they are overused by people that are just following the herd and can create a ton of accidental complexity.
Post reply on HN