Live data from Hacker News

A Critique of React Hooks

dillonshook.com

261–270 of 298 posts

Re: A Critique of React Hooks

#261

Earlier quoted context omitted.

= React.createElement(Foo, { bar: "baz" })

I don't understand how people claim this is hiding huge levels of complexity. It's trivial syntactic sugar. If stylistically, you don't like it, oppose it on those grounds. But complexity? It is syntactic sugar for a function call.

The opposition to it on fundamental grounds is born out of wrongheaded and misapplied best practices and quite frankly it needs to die. Dijkstra is credited with the idea of separations of concerns which is a valid application of code organizational management. The problem is, somewhere along the way (in the dawn of the web) we conflated separation of technology with separations of concerns. Thinking that separating technologies for technologies sake somehow made code more maintainable but the reality is, that it was dogma, if a snippet of JS, a snippet of CSS and a snippet of HTML will only ever be used as a black box component and only ever be reused as that black box component in total, separation of technology only leads to more complexity in interfile dependency and mental compos-ability of the whole solution in ones mind. There is an argument that separation of technology leads to simpler build management, but I personally will take a little more complexity in my build over complexity in the code base as usually a build becomes fairly static as a project matures.

Re: A Critique of React Hooks

#262
post #4

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

Hooks weren't invented because of 'this' complexity though, but rather as a better way to handle reuseable code (somewhat) akin to mixins.

Mixin's where a bad idea as well, they where basically just multi-inheritance lite. In all honestly I have never seen a mixin accomplish something that could not be accomplished by single inheritance and wrapping a private instance that contains the functionality one want's from the mixin. Sure it's a little more boilerplate, but it's understandable, uncomplicated and none-magic boilerplate. I am not down on Hooks per-say but I am skeptical of magic and hidden effects caused by code outside of the visible flow of code. Sometimes the magic is awesome but sometimes it's just not worth the hassle.

Re: A Critique of React Hooks

#263
The first three points are something that crops up in any moderately used library/framework, one way or another. Seemed a little bit like nitpicking.

The last two, now, do look like they can turn into serious problems (and a lot of confusing code) if one isn't careful.

Then again, I write this as someone who mostly uses, and vastly prefers, Vue so it's not like I'm an authority on react.

Re: A Critique of React Hooks

#264

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…

I don't think FP purity is the point of hooks, the advantage is the ability to compose them, more easily than HOCs.

Re: A Critique of React Hooks

#265
post #238

Earlier quoted context omitted.

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

None of that matters to a React developer. If you know JavaScript, you know JSX.

I don't understand how that is relevant to the quote I was replying to: "React is great because it's vanilla Javascript". Vanilla Javascript works in a browser with zero transpiling. That's important.

(also, "if you know JavaScript you know JSX" is objectively untrue! There are plenty of JS developers that don't work with JSX)

Re: A Critique of React Hooks

#266
post #94

Earlier quoted context omitted.

Huh? You can treat state as arguments to your function. For a given function evaluation, the state is stable. The fact that state can be changed during event handling is 100% irrelevant to the evaluation. There is no dynamic scoping.

I feel you don't understand how React function components work. From a purely functional standpoint everything a function should have access to must be passed in as an argument. Any state that exists is always external to the function. Therefore hooks like useState can't exist because it creates state within a function. This is not only weird from a purely functional perspective it's also incredibly weird from a regu…

[deleted]

Re: A Critique of React Hooks

#267

Earlier quoted context omitted.

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…

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

Re: A Critique of React Hooks

#268
post #94

Earlier quoted context omitted.

Huh? You can treat state as arguments to your function. For a given function evaluation, the state is stable. The fact that state can be changed during event handling is 100% irrelevant to the evaluation. There is no dynamic scoping.

I feel you don't understand how React function components work. From a purely functional standpoint everything a function should have access to must be passed in as an argument. Any state that exists is always external to the function. Therefore hooks like useState can't exist because it creates state within a function. This is not only weird from a purely functional perspective it's also incredibly weird from a regu…

Can you please give an example of React hooks 'dynamic scoping'? See https://stackoverflow.com/a/22395580 for an introduction to dynamic scoping.

React hooks 'state' variables are scoped to a single function. They are not arbitrary variables, but represent inputs to the program. The mental model is a function that produces the same output given the same inputs. Think of a dropdown, where the associated state variable D my have values a, b or c, depending on what the user chooses. The render function simply does not care how the value of D was set, and renders the exact same jsx given a specific D value: jsxa for a, jsxb for b and jsxc for c. That is as pure as it gets. Furthermore, the dropdown state variable D never represents the intermediate computation of some other component[s], and it's never changed by other components arbitrarily based only on the variable name.

The use of "dynamic scoping" to describe React Hooks state is unnecessarily imprecise, implying that a fairly well designed system is a specific kind of mess. Please don't engage in FUD.

Tip: Never call setFoo functions from render code. Only call setFoo from event code.

Re: A Critique of React Hooks

#269
post #265

Earlier quoted context omitted.

None of that matters to a React developer. If you know JavaScript, you know JSX.

I don't understand how that is relevant to the quote I was replying to: "React is great because it's vanilla Javascript". Vanilla Javascript works in a browser with zero transpiling. That's important. (also, "if you know JavaScript you know JSX" is objectively untrue! There are plenty of JS developers that don't work with JSX)

We're talking two different things. I'm talking about the developer perspective. You're talking about browser. If a JS developer doesn't work or understand JSX, they don't understand the fundamental concept of JavaScript which is what an expression is. "if you know JavaScript you know JSX" - JSX is just a JavaScript expression. There is nothing more to it.

Re: A Critique of React Hooks

#270
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?

I think the use of classes was just some sugar to help OO and Java people (like myself) into React components. They're not really classes in the useful sense, and I found my components littered with functions that returned blobs of JSX that felt too small to be factored into full "classes".

Smaller function components and then adding state with `useState` has simplified my code.

Post reply on HN