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

291–298 of 298 posts

Re: A Critique of React Hooks

#291

Post by lioeters »

fastball wrote: post #251
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…

It would be amazing if JS could have object equality in a performant way. I'm not sure if Python does anything interesting under-the-hood, but identical Python dicts have deep equality just fine. That would make hooks great in my opinion, where as right now they are just good. Dealing with object non-equality is like 90% of the friction I experience with hooks. Any pattern that requires me to reorganize my code (e.g.…

Not sure if it would fit with your use case, but for me, immer.js has been a game changer in terms of object equality/mutability.

https://immerjs.github.io/immer/docs/introduction

Once all state/object changes are being updated this way, a simple === can check for object equality. It's so useful, it makes me wish this was baked into the language itself.

Re: A Critique of React Hooks

#292

Post by jwr »

lilactown wrote: post #189
iLemming wrote: post #150

Earlier quoted context omitted.

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

Ok, so, what problem do Hooks solve for me, as a ClojureScript/Rum user?

(apart from compatibility with other libraries that use them)

Re: A Critique of React Hooks

#293

Post by schwartzworld »

mstudio wrote: post #240
schwartzworld wrote: post #193

Earlier quoted context omitted.

That's a misuse of useEffect. it's much simpler to wrap the set function and just call your other function afterward like this: ``` const handleChange = (value) => { setMyState(value); doSomething(); } ```

This does not work. setMyState() is asynchronous. doSomething() would run, but not necessarily with the updated value of the state.

Then make the wrapper function async and await setMyState?

Re: A Critique of React Hooks

#294

Post by mikestop »

I've found hooks incredibly easy to reason about, and I'll happy take the bit of magic that goes along with it. (Anyway, I don't see any of you criticizing JSX for being magic.) On the other hand, I really like functional programming, so I've seen the entire development path of react as positive.

Re: A Critique of React Hooks

#295

Post by futureproofd »

cageface wrote: post #188
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 wi…

The knowledge-gap of closures is simply an indication that you need to solidify your Javascript foundation prior to understanding hooks. I only see this as a benefit.

Re: A Critique of React Hooks

#296

Post by untog »

greatwhitenorth wrote: post #281
untog wrote: post #272

Earlier quoted context omitted.

> We're talking two different things. I'm talking about the developer perspective. You're talking about browser. I'm not. I'm talking about a programming language. It has a spec. "if you know JavaScript you know JSX" - JSX is just a JavaScript expression. This is nonsense. Where is JSX in the JavaScript spec?

You talk nonsense just for the sake of it. I never said JSX is in the spec. If you know JavaScript basics (what an expression is), it takes a minute to understand JSX.

You're talking about something different to me then criticising me for it. The quote I was originally replying to was:

> React is great because it's vanilla Javascript

React is not vanilla Javascript. "it takes a minute to learn JSX" isn't disgreeing with that statement.

Re: A Critique of React Hooks

#297

Post by lilactown »

jwr wrote: post #292
lilactown wrote: post #189

Earlier quoted context omitted.

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

Ok, so, what problem do Hooks solve for me, as a ClojureScript/Rum user? (apart from compatibility with other libraries that use them)

Here's a rundown on mixins vs. hooks: https://reactjs.org/blog/2016/07/13/mixins-considered-harmfu...

I haven't used Rum in anger, but I do use reagent at work, and there are compatibility tradeoffs not just with other libs but also React itself that storing lots of state outside of the component tree in a mutable ref causes.

There's potentially a lot of work to be done to support React concurrent mode, which has a measurable impact to the user experience of apps that we build. Following best practices set by the React team - including using hooks for sharing and composing behaviors - sets us up better to take advantage of that in the future.

Ultimately though you don't need to rewrite your Rum/reagent apps, but instead there's an onus on the maintainers of those libs to build scaffolding around their lib code and encourage their users to migrate in a direction that will benefit them.

Re: A Critique of React Hooks

#298

Post by thatswrong0 »

efdee wrote: post #267
com2kid wrote: post #243

Earlier quoted context omitted.

The problem I have with hooks is that I see cool examples like the window size watcher, but when it comes to my own code I have: 1. Some stuff that happens when the component gets mounted 2. So local state that gets maintained (shown error text, whatever, red x, whatever) 3. Some stuff that happens when the component is unmounted. React classes fit 99% of my use cases. Yes HOCs to get navigation and stuff working is…

But these three things are super easy with hooks, maybe even easier so than with class components.

Exactly. I'll often use a shared useOnMount and useOnUnmount for additional clarity for those in our codebase unfamiliar with how useEffect works.. there's nothing preventing you from writing custom hooks to replicate the effect of lifecycle methods for the transition period.

For the simplest cases, class components might be clearer with its clearly labeled lifecycle methods. But most of the time, if I have multiple different things happening on mount, hooks are definitely simpler as you can divide / encapsulate based on feature functionality rather than lifecycle.

This is my favorite example for showing how this effects code structure: https://twitter.com/threepointone/status/1056594421079261185

If you then extract those bits into custom hooks in order to name that piece of functionality (e.g. in that example, useTitle() and useWindowResize()), the clarity improves dramatically.

Post reply on HN