A Critique of React Hooks • Hacker News Board

Re: A Critique of React Hooks

#231

Post by desert_boi » Tue, Apr 28, 2020, 3:44 AM UTC

pcr910303 wrote: post #206

throwanem wrote: post #58

Earlier quoted context omitted.

Who says functions don't have state? Referential transparency requires no such constraint; it only requires that state not leak into or out of a pure function save through its arguments (inward) and return value (outward). Beyond that, what they do within the space of their own lexical scope and the lifetime of their call stack frame is entirely their own business. I'm familiar with dynamic scoping via Emacs Lisp. I…

> it'd be surprising in any case to encounter dynamic scope in Javascript, a language which does not even support it. Doesn't matter much, but just b.c. it's interesting: JavaScript actually does support limited dynamic scoping - `this` is scoped dynamically like in usual Lisps, and there's a with statement[0] that acts somewhat similar with `let` in Lisp. [0] https://developer.mozilla.org/en-US/docs/Web/JavaScript/R…

`with` is not allowed in strict mode (from ES5) and with ES modules (which imply strict). It's a bit of a relic.

Re: A Critique of React Hooks

#232

Post by acemarke » Tue, Apr 28, 2020, 3:46 AM UTC

yawaramin wrote: post #217

lhorie wrote: post #172

Earlier quoted context omitted.

Right, I meant that Sebastian is the current maintainer. Not to detract from Dan Abramov etc, but the feel I get is that Sebastian is the one who really sets the pace for where React is going these days (i.e. hooks, suspense, etc). Correct me if I'm wrong.

Well, you're factually wrong. Abramov is the current React maintainer. Markbage is obviously a core team member but contributing good ideas doesn't automatically transform one into being the project maintainer.

Uh... there's not a _single_ React "maintainer". There's a React _team_, which currently consists of:

- Seb Markbage: general deep thinking and vision, works on Suspense and some of the server rendering

- Andrew Clark: implemented much of the Suspense and Concurrent Mode core

- Dan Abramov: started Create-React-App, wrote the hooks and Concurrent Mode docs, works on various parts of the library and tooling

- Brian Vaughn: rewrote the React DevTools, added the Profiler, recently implemented the upcoming `useMutableSource` hook

- Dominic Gannaway: previously created Inferno, now works on a lot of the upcoming new event system and other optimizations

- Nicolas Gallagher: previously created React Native Web, now also works on the event system

- Luna Ruan: newer to the team, helped implement the `useOpaqueId` hook that just got merged

- Rachel Nabors: currently working on revamping the docs and community outreach

They have a team bio page here:

https://reactjs.org/community/team.html

Re: A Critique of React Hooks

#233

Post by acemarke » Tue, Apr 28, 2020, 3:48 AM UTC

afranchuk wrote: post #210

I've been out of the React game for a while, and this is the first I've read about Hooks (or at least the first time I read enough to look into them). If I understand things correctly, they are automatic dependency tracking functions that will rerun as needed? Kinda like S.js [1]? Though that's different in that it's built around only that functionality, not integrated into a larger system. [1]: https://github.com/ad…

Not exactly.

I'd strongly recommend reading through the React hooks docs, as well as the other hooks resources I have linked here:

https://github.com/markerikson/react-redux-links/blob/master...

Re: A Critique of React Hooks

#234

Post by acemarke » Tue, Apr 28, 2020, 3:49 AM UTC

didericis wrote: post #216

efdee wrote: post #13

Earlier quoted context omitted.

The reason they introduced hooks was exactly that component lifecycle and decorators/higher order components were found not to scale well in larger codebases (as experienced by the people using React at Facebook). The useEffect pretty much provides a direct replacement for componentDidMount/componentWillUnmount. I'm still on the fence, but so far it seems to me that using hooks makes my intent clearer than using the…

Can you provide links to articles where react devs detail the scaling issues? I've found HOCs easy to combine and reason about if I name them carefully, and am still using them on personal projects. When people complain about HOCs not scaling well, are they primarily complaining about name collisions, or performance issues due to deeply nested components/lots of render calls?

It's primarily about naming collisions and indirection.

I covered some of the tradeoffs in this post and talk:

https://blog.isquaredsoftware.com/2019/07/blogged-answers-th...

https://blog.isquaredsoftware.com/2019/09/presentation-hooks...

Re: A Critique of React Hooks

#235

Post by omniscient_oce » Tue, Apr 28, 2020, 3:51 AM UTC

Sophistifunk wrote: post #214

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…

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 really seem to be 'functional' in the functional programming sense, but more the 'we use the function syntax of JS' sense. I don't know haha.

Re: A Critique of React Hooks

#236

Post by kin » Tue, Apr 28, 2020, 3:58 AM UTC

jonny_eh wrote: post #157

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…

I never understood what was wrong with class components anyways. What did Hooks bring that couldn't be done in an easier to understand way with class components?

The problem wasn't the fact that components were classes. The problems were the React lifecycle methods. People did some crazy things with instance variables, shouldComponentUpdate, and componentDidUpdate, and especially the deprecated componentWillReceiveProps.

Re: A Critique of React Hooks

#237

Post by kin » Tue, Apr 28, 2020, 4:04 AM UTC

azirbel wrote: post #223

I really like hooks. I previously spent a lot of time in HOCs, and I find hooks much simpler. But I also have problems with #5 (control flow): The main issue I have with hooks is that I can't easily trace why updates are being triggered in my app; this makes it hard to debug performance issues. For example, my app once got really slow, and the profiler told me that a root(ish)-level component was causing a lot of re-…

Not sure if this helps or is relevant, but I like to think of a component as a physics function.

For example, at t = 0, the output is one thing. When t = 1, the output is another. The same way of thinking can be applied to hooks. Some hooks only execute at t = 0, and at that time, variables x, y, and z also have specific values.

Hopefully you can think this way and your values won't intertwine so much that it becomes hard to trace.

Re: A Critique of React Hooks

#238

Post by untog » Tue, Apr 28, 2020, 4:13 AM UTC

greatwhitenorth wrote: post #207

untog wrote: post #137

Earlier quoted context omitted.

> React is great because it's vanilla Javascript What about JSX? It’s very useful but it’s also an absolutely huge departure from vanilla JavaScript and hides a fair amount of complexity behind what your code is actually doing.

JSX is 99% map/filter and boolean expressions. It's written between curly braces to be evaluated as a JavaScript expression. I don't understand how it's different from regular JavaScript.

It uses tag syntax, which regular JavaScript doesn’t at all. Browsers cannot parse it. These are meaningful differences.

Re: A Critique of React Hooks

#239

Post by coffeefirst » Tue, Apr 28, 2020, 4:24 AM UTC

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…

Yes, I honestly wonder if, with a few minor changes to make it more conventional js, you could address a lot of the criticism.

Suppose you replace:

  const [count, setCount] = useState(0);

with

  const [count, setCount] = this.useState("count", 0);

I'm just speculating idly, but if you use `this`, it's clear how the function knows it's component. If you pass an explicit key, I don't think you need the order to matter. And if the order doesn't matter, well, conditional logic ought to work normally, even if it's a bad idea?

I have no idea if there's a compelling reason this wouldn't work, but if it would, it seems like it could take a lot of the magic and nonstandard behavior out of the API.

Re: A Critique of React Hooks

#240

Post by mstudio » Tue, Apr 28, 2020, 4:33 AM UTC

schwartzworld wrote: post #193

mstudio wrote: post #19

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

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.