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

251–260 of 298 posts

Re: A Critique of React Hooks

#251

Post by fastball »

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. passing in individual parts of an object rather than just the whole object to the dep array) is an inelegant pattern, imo.

Re: A Critique of React Hooks

#252

Post by TomMarius »

lhorie wrote: post #91
kiliancs wrote: post #84

Earlier quoted context omitted.

Was it sold as "just a view library" from official sources? I understand "just a view library" might have been used to contrast it to full framworks that dictate a lot more than React, but it's important to note that the key React feature compared to other view libraries is precisely that it's not "just a view library": state is at its core. It's hard to disagree with the the pain of React having to leave the comfort…

> Was it sold as "just a view library" from official sources? Yes, the "V in MVC" term came straight out its main page: > JUST THE UI > Lots of people use React as the V in MVC. Since React makes no assumptions about the rest of your technology stack, it's easy to try it out on a small feature in an existing project. https://web.archive.org/web/20140321012426/http://facebook.g...

I don't see any contradiction - you still need controllers and models today. It's a front-end view library, so it manages state, but nothing else (unless you make your controllers and models a part of the view, which was possiblewith server side views just as well - remember PHP?)

Re: A Critique of React Hooks

#253

Post by imtringued »

pacala wrote: post #94
deckard1 wrote: post #42

Hooks elucidate everything I've felt wrong about React, but have not been able to put my finger on it until recently. Hooks reveal two major things with React: 1) React developers did not understand the component paradigm that they originally went with. If they did, then they would understand how silly it is that components cannot reuse logic. This was an entire debate many years ago. Composition vs. inheritance. You…

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 regular OOP perspective because that state should have been declared inside a class or struct. Therefore it is neither pure FP nor pure OOP. It's a random mix of both but it fools beginners into thinking that because it is not OOP it surely must be functional programming.

The reality is that a component in React is still a class with internal state. React hooks are merely using a reference to "this" behind the scenes to store state but hooks are the only way to access that state. Therefore React hooks are basically a small DSL that adds features like dynamic scoping which is why lots of people think that this isn't regular Javascript anymore.

Re: A Critique of React Hooks

#254

Post by lucideer »

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

This.

The article would be completely contentless if not for pointing out the genuine pain that is JS object equality (the issue is that this is a JS pain and not a React pain: hooks just makes it more apparent).

The only thing I'll say is that battling with this pain has tended toward my inventing less generalised but more readable/maintainable/elegant solutions to most individual problems where I've encountered it. e.g.:

- object equality would solve this problem easily :(

- maybe I should've enforced strict immutables throughout?

- oh maybe I could approach it differently. Yes, let's try solution X

- hmm solution X isn't very reusable but it sure is clear and intuitive to read

Re: A Critique of React Hooks

#255

Post by Normal_gaussian »

kin wrote: post #236
jonny_eh wrote: post #157

Earlier quoted context omitted.

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.

very much this. I had to refuse a lot of code because developers were using these in inconsistent, confusing, and actually incorrect (read buggy) ways.

Re: A Critique of React Hooks

#256

Post by valand »

com2kid wrote: post #242
baron816 wrote: post #205

Earlier quoted context omitted.

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

React team made the wrong separation of problems with hooks.

Class component should lose its ability to render and replace it with attach functional renderer. In its place, class component should have composable and detachable state and substates with their own lifecycle, each communicating via events within the same context.

It will be truer to `ui = fn(state)` principle.

This is a result of contemplation after learning what the functional people and rust community are doing, and then coming back in front of my laptop showing my professional project in React and TypeScript.

Unstated (https://github.com/jamiebuilds/unstated) is a library that helps scoping and lifecycle separation.

I used in-house event library but there are a couple of libs out there providing this functionality like https://github.com/KeesCBakker/Strongly-Typed-Events-for-Typ...

It took me months to experiment and reach the decision which finally helps the team to write and iterate faster. I hope this will help everyone facing those React problems.

Re: A Critique of React Hooks

#257

Post by valand »

dcre wrote: post #28

An important point I don't see being made in the article or the comments is that hooks are meant as a more faithful (or at least less misleading) representation of what was going on under the hood in React already. The problem with the JS class representation is that people already understand what classes and instances are, and that leads to incorrect inferences about how React is working. In addition to better-organ…

> The problem with the JS class representation is that people already understand what classes and instances are, and that leads to incorrect inferences about how React is working.

The same goes for hooks. People already understand what functions and js scope are and that leads to incorrect inferences about how hooks work.

Even more severe, newcomers who learn hooks while learning JS at the same time will get deformed perspective on how functions and scope work in JS outside of React world.

Re: A Critique of React Hooks

#258

Post by lioeters »

e12e wrote: post #144
lhorie wrote: post #48

Earlier quoted context omitted.

It's interesting that the original appeal of React was that it was "just a view library", but now apparently it's more like a "language". It really shows the biases of the maintainers (the "just a library" thing being a philosophy I liked from vjeux, and the "language-likeness" being very obviously a heavy influence from sebmarkbage). The thing w/ "language-ness" (as opposed to "library-ness") is that additions and c…

> It's interesting that the original appeal of React was that it was "just a view library", but now apparently it's more like a "language" Well, it was prototyped in standard ml first[1], wasn't it? - then ported/re-implemented (shoehorned ;) into plain js. So some things that sml has, and made sense in sml, had to become part of the library/language/framework that is react? Later came reasonml (a ocaml dialect) whic…

Thank you for this latter link where the original author of React describes its beginning.

After reading it, I finally feel like I'm starting to understand where React came from, why it's designed the way it is.

The paradigm shift that React brought to JavaScript was to "bend the language" to implement concepts and design patterns from ML, a functional language with roots in Lisp, with static typing, algebraic data types, and foundation in lambda calculus and category theory.

When you joked that it was "shoehorned" into JS, I got an insight into the reason why some design decisions in React feel awkward and strangely non-idiomatic. It explains, in part, the strong emotional reactions seen in this discussion thread, a number of justified opinions, its problems as well as benefits.

I've been skeptical of the design of React Hooks, and still am, but now I'm interested in learning its influences, to understand the logic behind them. I wish that it had been implemented to be more "React-agnostic", like JSX, as generic extension to the JavaScript language.

Re: A Critique of React Hooks

#259

Post by kls »

shoulderfake wrote: post #191
stevebmark wrote: post #149

Earlier quoted context omitted.

I have never fundamentally understood sagas and I've tried a few times. I'm able to wrap my head around redux-loop though https://github.com/redux-loop/redux-loop

They're just redux middleware implemented with generators, so you can do some nifty things with it if your use case requires. I've used sagas on a several projects and they all actually did need that type of tool but I've chosen thunks on other projects when fetching logic was simple.

I tend to use Sagas now as my go to but I am comfortable with them. I would agree with most of the sentiment on here that they are more complex, though not because of Saga's API but because one really has to understand the core workings of the framework to not screw the pooch. For many their first exposure to generators is via Saga and that is just the tip of the iceberg. One really needs to understand what all the takes are doing as well as how Saga utilizes async and await style logic. To me, Saga's a very readable and very easy to debug but some dragons lie below the API and one has to understand that those dragons are doing magic a lot differently that other frameworks do magic. It's just not a framework where you get to ignore what the magic is doing for you as you will create nasty bugs due to lack of understanding about what the framework is trying to do and it becomes easy to fight against it out of ignorance. That being said, my general opinion is that I like Saga and we generally choose to use it as a team.

Re: A Critique of React Hooks

#260

Post by greatwhitenorth »

untog wrote: post #238
greatwhitenorth wrote: post #207

Earlier quoted context omitted.

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.

None of that matters to a React developer. If you know JavaScript, you know JSX.
Post reply on HN