Live data from Hacker News

A Critique of React Hooks

dillonshook.com

241–250 of 298 posts

Re: A Critique of React Hooks

#241

Earlier quoted context omitted.

This. So much this. You are 100% correct. Hooks are incredibly stupid. No, your component is not "functional" because you don't use the word "this". You still have a "this", it's just fucking secret now so your debugging is harder. I could go on about all the other reasons hooks are stupid, but JavaScript is largely a cargo cult and I'm a nobody so I'd just be wasting my breath.

I honestly don't know how hooks work that well but I find them easier in general to make quick reusable stuff or just plug things in without having to worry about layers deep of Higher order components. There used to be class = logic , pure function = takes data and outputs jsx. But now functional components manage their own state and somehow trigger rerenders of themselves (how do they do this btw?). So they don't r…

> (how do they do this btw?)

these links might help explain

https://medium.com/@ryardley/react-hooks-not-magic-just-arra...

https://dev.to/kayis/react-hooks-demystified-2af6

Re: A Critique of React Hooks

#242

Earlier quoted context omitted.

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…

> Manually managing your dependency graph and memoizing in all the right places I wouldn't say it's harder, but it's certainly not simple. There are a handful of mistakes that I see repeated, but if you get over those hurdles, you can significantly simplify your components 99% of the time. It was very easy to have huge componentDidMount and componentDidUpdate methods in class components, and with logic scatter shot a…

I have yet to see any real code that got simpler from hooks.

I have classes that need to do stuff when they appear on screen and that need to clean up when they are unmounted. They also have some local state.

Hooks make doing all that messier. Class components make doing it easy to read and sensible.

Re: A Critique of React Hooks

#243
post #95

Earlier quoted context omitted.

But that took the simplicity away. Everyone that knows modern JavaScript knows classes. Now they have to learn this alien concept called "hooks". Now regarding reusability: I have been doing UI code for many many years and I have rarely felt that logic inside UI components need to be reusable. First move all business logic out of UI components into model-layer objects. This eliminates most of the need for reusable lo…

You're only calling it not simple because you're not familiar with it. I personally think hooks are simpler despite being different. Everyone knows "classes" but React's usage of them is not typical and there _are_ non-standard behaviors about using them that you have to learn when learning React (because the classes necessarily exist within the React runtime). Either way you're dealing with React. And on a day-to-da…

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 a pita. But honestly I'd have preferred a way to get the cool hook stuff added to class components instead of adding all the class component stuff to function components!

Re: A Critique of React Hooks

#244
post #228
post #202

Earlier quoted context omitted.

But everything in that dependency array is from lexical scope, correct? Your hooks execute in the scope of that call to MyComponent().

Correct, but the callback passed to useEffect is only scoped to the call stack triggered by the dependency array. So, this makes the callback passed to useEffect dynamically scoped.

The callback is always defined it's just not always invoked. Otherwise it's a regular lexical closure like any callback in JavaScript. Maybe I'm not understanding what you mean by dynamic scope.

Re: A Critique of React Hooks

#245

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…

Although I haven't criticized Hooks, I humbly accept the fact that there are flaws in my argumentation. You are right.

Re: A Critique of React Hooks

#246
post #67

Earlier quoted context omitted.

> and the "language-likeness" being very obviously a heavy influence from sebmack just a minor correction, you probably mean seb markbage, who works on React, not seb mackenzie, who made Babel and now Rome and i dont think was ever on the React team. i agree that when seb markbage leaves, it will be a big test of React's legacy. I've called it the "Ship of Theseus" moment for React.

Got a link to Rome's docs? Babel is a little easier to google for.

https://github.com/facebookexperimental/rome

Re: A Critique of React Hooks

#247

Earlier quoted context omitted.

For example Angular templates, stuff like Razor in .NET, etc?

Perhaps I have missed the point, then. I see the same magnitude of departure of Razor from pure C#, QML from pure Qt C++, and JSX from pure DOM JS. All of the above move the developer from procedural native code, to declarative markup. If the assertion is just that `var div = document.createElement('div')` is quite similar to `var div = React.createElement('div');` then of course I agree. In this sense, JSX+React is…

> From a UI standpoint, it would be virtually just as hard for a JSX dev to implement a React app with purely `React.createElement()` as it would be to just write a native DOM application

I don't think that's true at all. I find react-hyperscript[0] and friends terser, more regular and just as easy to work with as JSX.

[0] https://github.com/mlmorg/react-hyperscript

Re: A Critique of React Hooks

#248
post #67

Earlier quoted context omitted.

> and the "language-likeness" being very obviously a heavy influence from sebmack just a minor correction, you probably mean seb markbage, who works on React, not seb mackenzie, who made Babel and now Rome and i dont think was ever on the React team. i agree that when seb markbage leaves, it will be a big test of React's legacy. I've called it the "Ship of Theseus" moment for React.

Got a link to Rome's docs? Babel is a little easier to google for.

https://github.com/facebookexperimental/rome

It's interesting. Everything is from scratch. No depa what so ever.

Re: A Critique of React Hooks

#249

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…

[deleted]

Re: A Critique of React Hooks

#250

Earlier quoted context omitted.

This. So much this. You are 100% correct. Hooks are incredibly stupid. No, your component is not "functional" because you don't use the word "this". You still have a "this", it's just fucking secret now so your debugging is harder. I could go on about all the other reasons hooks are stupid, but JavaScript is largely a cargo cult and I'm a nobody so I'd just be wasting my breath.

I honestly don't know how hooks work that well but I find them easier in general to make quick reusable stuff or just plug things in without having to worry about layers deep of Higher order components. There used to be class = logic , pure function = takes data and outputs jsx. But now functional components manage their own state and somehow trigger rerenders of themselves (how do they do this btw?). So they don't r…

> don't really seem to be 'functional' in the functional programming sense, but more the 'we use the function syntax of JS' sense

That's right. A true function has referential transparency. I get that hooks have ergonomic benefits in some situations, but I wish people wouldn't call them "functional".

Post reply on HN