A Critique of React Hooks | Hacker News Reader

A Critique of React Hooks

dillonshook.com

247 pointsvicarrion290 comments

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 eventually if you're building anything without knowledge of all the contexts in which it's called.

There's a reason that most languages stick to lexical scoping: you can see the dependencies, in the same file.

And a large portion of the value of functional languages is that they avoid state, making magic-at-a-distance impossible.

Boilerplate is not the problem. Magic is the problem.

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?

Hooks allow for declarative behaviour that’s harder to model other ways. With hooks, something like declaring when an event listener should be in play becomes much cleaner. The alternatives with class components are messy.

The above criticism that you don’t get to have pure functional components anymore doesn’t really make sense to me - either you have some lingering state to deal with, or you write a pure function. Your hand is forced by the problem. You could switch over to class components but they’re really not much clearer to read.

Most of the bugs I’ve seen have been around JavaScript’s crummy equality checks and the need for more memoisation.

I found class components really....wordy binding this to this all the time and lifecycle methods could become kinda wild after a while doing all these checks for a bunch of things...and imo that just trended towards these bulky spaghetti class components / lifecycle methods.

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.

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.

Yes. Except mobx ;) I like to use function components together with class based observable view models. Only a single hook wires them up. Works like a charm and avoids all the IMHO confusing hook complexity.

Hmm, so the reusable bit is the straightforward inject-everything component, driven by an app-specific, app-aware hook-using part?

I can see how that can work for simple cases. Nesting components is going to get tricky though if the classes don't operate exactly the way the hooks expect.

Of course that's the problem: someone built hooks for their trivial cases and now they're the 'preferred' approach...

Edit: To clarify, 'simple' is going to be context-dependent since hook behaviour is. If your 'driving skeleton' of hook-based components is in the direct uninterrupted ancestry chain of every class component, you're probably using hooks in a near-ideal case.

This is how we use it: https://imgur.com/a/I6BD4vF To be honest, we abstracted hooks away.

It works for arbitrary complex cases.

The React team’s claim (see my other comment) has been that by using React at all, you are already fully bought into all this magic, it’s just harder to tell.

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 without the baggage.

> 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 across a big file without the ability to easily reuse bits of it.

I converted a medium-sized React codebase from classes to hooks. In most cases it simplified the components and eliminated boilerplate. But it also introduced more than a few very tricky bugs and serious performance regressions that were not trivial to fix.

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.

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.

I don't really understand this. Can you explain how hooks relate to dynamic scoping?

Basically every call of a functional component MyComponent() represents a new scope. When you're working with a hook such as useEffect(), you have to pay attention to the dynamic scope so and correctly trigger the useEffect() with the dependency array.

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.

Yes, it's just regular lexical closure. I don't think his comment was literal since JS itself is lexically scoped. If you think about how `this` works in JS, it's very similar to dynamic scoping because it matters where the function is called.

With hooks and dependency arrays, similar to dynamically scoped languages, it matters where the function is called.

Thing is, people rarely write functions and use `this` is in dynamically scoped ways anymore. Remember when you had to explicitly bind function scope everywhere? With ES6 and arrow functions, I don't miss that.

Anyway, hooks forces you into that mindset now.

Absolutely 100% agree; Reactive programming environments become easily unmanageable unless they are Functional Reactive Programming for the exact reason you state. Hooks are a way to manage that complexity from an imperative perspective with the illusion of a declarative veneer.

I for one preferred the diplomacy.

The 'magic' involved in hooks is a tradeoff; there are real benefits in the way you can consolidate logic, or mix in behaviors. Personally, I strongly prefer hooks to HOCs.

Many technologies have magical behaviors and are still very popular and useful (Rails comes to mind). I'm really liking the pros and cons being brought up in the rest of this thread.

> Personally, I strongly prefer hooks to HOCs.

To me this is the most visible win. useSelector for Redux, useIntl for react-intl, useHistory for react-router, useStyles for material-ui, etc. Almost every library I use radically simplified their API by adopting hooks.

It also makes types much easier to analyze (whether using, say, VSCode's inference or Typescript) when using hooks. With HOCs, types tended to get lost through the arbitrary amount of <Wrapped {...props} /> chains.

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.

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

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

Who is saying that, the point of hooks is composability.

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

How objects work: there's a lookup table for methods and properties associated with your instance to find them by name (or call signature, or whatever).

How hooks work: there's a lookup array associated with your instance (yes, an instance of an object—read the code if you're skeptical, and besides functions are objects in JS anyway so even if I'm wrong, which I'm not, I'm technically right) to find properties and methods by reference order(!?!)

Hooks are just a crippled implementation of objects with weird syntax. In a language that already has non-crippled ones built in with less-weird syntax.

So, closures are indeed poor man's objects.

It's storing all the hooked-in functions (methods) and variables (properties) outside the function and associating them with the relevant React view object instance at run-time, which is effectively the hooks' "this". Unless the code's change substantially and in very fundamental ways since it was introduced. It doesn't bring to mind closures, at least as I read it. It very much brings to mind object/class-system implementations.

well, from my point of view i write 40% the amount of code with react hooks than i did with react classes, i probably reused about 40% more code, and can write components 50% faster than before. i also refer to React documentation about half as much as before.

not sure what's 'fucking stupid' about that.

it might be harder to grok at first - but that's the reality of tools - by nature, they get more complex but more elegant, i think it's fucking stupid to want to go back to componentDidMount()componentDidUpdate, componentWillReceiveProps, componentWillUnmount, getDerivedStateFromProps and UNSAFE_componentWillUpdate. like... really?

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-organized code, the hooks abstraction is partly aimed at preventing people from making those wrong inferences. This also explains why they are uncomfortable compared to classes and functions — the point is that was a false comfort because those representations are misleading.

Dan Abramov calls hooks a "missing primitive":

"Why are these models insufficient to describe React? “Pure function” model doesn’t describe local state which is an essential React feature. “Class” model doesn’t explain pure-ish render, disawoving inheritance, lack of direct instantiation, and “receiving” props.

What is a component? Why do you start writing it one way and then have to convert into another way? Why is it “like A but also like B”? Because it’s neither. It’s a thing of its own. A stateful function with effects. Your language just doesn’t have a primitive to express it.

That’s what Hooks are. Those missing primitives. They are library-level but conceptually they are part of the “React language”. Hence the language-like “rules”.

They could be syntax. They would be in Eff or Koka. But the benefits are not worth the friction it creates in JS."

https://twitter.com/dan_abramov/status/1093696560280596491

https://twitter.com/dan_abramov/status/1093697963350810624

https://twitter.com/dan_abramov/status/1093698629708251136

As a user of a library, I don't really care how it works. Under the hood it can be arbitrarily complex or simple, and please feel free to change the implementation weekly for all I care. I care very deeply about my own components, when they render, what causes them to re-render, and that I can control and reason about when they re-render. Also, stability of API (in number of years) is way more important than new whiz-bang features.

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 changes to a language tend to become more and more difficult to make over time because semantics deeply affect everything in the system, whereas well designed APIs in a library-oriented approach can be well encapsulated.

I've said for a while, for example, that throwing promises for Suspense is using up "escape hatches" in JS. The rule of hooks is another one of those. Eventually, the React team will run out of escape hatches to implement "React language" semantics around the real JS semantics, and I suspect at that point sebmarkbage will move on to create a new view framework (as has been the case w/ e.g. sebmack and babel/rome, Rich Harris and ractive/svelte, etc).

It'll be interesting to see if whoever steps up to maintain React at that point will be able to grok its internal complexity, and to see how the community reacts to a rift when their favorite view library team pushes for one vision but the moved-on "rockstar facebook engineer" pushes for a different vision.

EDIT: fixed name confusion (thanks, swyx!)

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

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 of plain idiomatic JS to better fulfill its goal, but to me React's efforts are in a way an experiment to find some primitives that should be baked into JS engines to allow for these mature, fine tuned experiences without putting the burden on the library.

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

Thanks for finding that! Yes, it seems like this way of seeling it could cause false expectations. It is still true, though, that "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".

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?)

> It'll be interesting to see if whoever steps up to maintain React at that point will be able to grok its internal complexity, and to see how the community reacts to a rift when their favorite view library team pushes for one vision but the moved-on "rockstar facebook engineer" pushes for a different vision.

Kind of what is going on with Node / Deno... and like the chap who quit the Angular 2 team to start Aurelia hoped would happen to him (sorry buddy!). My guess is that he'll find out that there is more to a framework than rockstar developers. Like Facebook backing, or like UX designers being in love with your library because it reflects their approach to problem solving. Like CRA, hot module reloading and all that jazz. These are all things that put React where it is today

> 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) which is a lot closer to sml than js - and I think the state handling reflects that, like the readme for reasonml variant of redux:

https://github.com/reasonml-community/reductive/blob/master/...

"The code behind Reductive is incredibly simple. The first 40 lines include the entire re-implementation of redux. The next ~40 lines are a re-implementation of the react-redux library (without the higher-order component connect style implementation)."

In a sense, react has always been a design pattern - and a library to support/enable that pattern in Javascript.

[1] https://www.reactiflux.com/transcripts/jordan-walke#come-ide...

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.

You're very welcome. I do believe looking at reasonml and reasonreact is a good way to gain insight into reactjs. It's on my (so very long) to-do-list.

Ed: as an example, I found this (oldish) post on hooks in reasonreact:

https://dev.to/iwilsonq/reasonml-with-react-hooks-tutorial-b...

Compare as you will with a comparable one for reactjs:

https://upmostly.com/tutorials/build-a-react-timer-component...

Note - I would advice looking at the reasonreact documentation for up to date tutorials and guides... It's a quickly changing landscape.

Eg:

https://reasonml.github.io/reason-react/docs/en/usereducer-h...

Finally I came across this - I thought maybe a sibling comment mentioned it - but a quick search didn't turn up anything - but imo it's a pretty strong argument for hooks (in js react) :

https://tylermcginnis.com/why-react-hooks/

Nice resources! I've bookmarked them for later study.

That last one I like, especially where the author recommends to "forget everything about lifecycle methods" and think of hooks in the context of synchronization. It makes sense, as a declarative way to describe state and state transitions.

The aspect that's unsettling is that they're not idempotent pure functions, but rather deeply tied in with how React works internally. They can't be used outside of React, and require the programmer to understand the magic that makes them stateful.

The common issues that beginner users of hooks encounter, like the "captured scope" of variables, or that hooks must be run in the same order every time, never conditionally - I suppose these are some reasons that make me (and other hook skeptics) react to them as "code smell". If someone had designed a library totally unrelated to React this way, I wouldn't want to use it.

Looking at ReasonML, it's quite elegant and intuitive how React Hooks fit in. In fact, the code examples look very similar to how I structure my React projects, with state and actions (instead of a reducer or Redux, they use immer for immutable state changes).

I'm staying open-minded about hooks, and I think the more I learn of its roots, the more I'll come around to accepting them as part of idiomatic React.

I thought Jordan Walke created React, not Sebastian Markbåge, in which case he already moved on (to ReasonML)

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.

Didn't mean it as an XOR. FWIW, looking at the github commit history one might get the impression that acdlite is the main committer in the repo these days, followed by trueadm and bvaughn (gaeron doesn't look all that active recently in comparison). I don't really hear those three core team members talk much about JS since their twitters tend to be less technical. My impressions come mostly from what I see the more technically-vocal react team members say publicly and I feel like gaeron often makes it sound like the bulk of react concepts are other people's contributions. Markbage certainly seems like the "vision" person in the team </shrug>

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

Thank you for the correction. I didn't realize they structured the team without a 'maintainer' role.

isn't react created by jorde walke?

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

I feel like that "appeal" was part of the marketing but the designers always wanted to create a new language. I switched a fairly large webapp from Angular to React pretty early on and I remember thinking that Flux (the design) was designed by someone that wished they were programming in OCaml instead. The whole "constants.js" for actions felt like a kind of defeat that they couldn't have unions and pattern matching in JS.

> A stateful function with effects. Your language just doesn’t have a primitive to express it.

I wonder what about generator functions?

Yep, there was even a library making the rounds recently that leverages them: https://crank.js.org/

Another example: Redux Saga has been using them in React for a long time. https://redux-saga.js.org/

I don't see how generators would change anything here. "with effects", "stateful", and the integration between the two are all equally important in the statement.

Well generators are a good primitive to represent "stateful" "functions" "with effects". The concept of hooks, which somehow give the control back to React to do something, map marvelously to react.

I'd be surprised if generators didn't come into React at one point or another

There are two different concepts as I see it, please correct me if your definitions differ.

"stateful": A function that has state, i.e. can store data

"with effects": A function that modifies data outside its own scope

Normal JS functions (as opposed to arrow function) already do this:

function foo(){};

foo.state = bar;

Generator functions take it a step further, where the function remembers internal state between calls.

What are generators for you?

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

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 Hooks Limit Your Design

This is an interesting section but seems to point to a pattern that would lead to serious issues given any library/paradigm. It's criticising the Rules for their inflexibility, but in this instance they're helping you by pointing out the pitfalls of your approach, and encouraging you to rethink it.

An alternative way of looking at it is that it's again (like in 5) bemoaning Javascript's object inequality which is prevening the memoization here.

The other 3 bullets are pretty silly "boo new things" issues that are common to migration to any new API.

Agree, "More Stuff to Learn" isn't really a critique of hooks, it's a critique of learning.

Yeah, I don't really get this criticism in regards to hooks. I think it took me maybe an hour to learn them. That's basically nothing.

I've never* used hooks and I only got 1 question wrong in the author's Google Forms quiz (would've been 2 wrong, but bullet point 4 had already signposted the object equality gotcha).

So there doesn't seem to be a huge amount to learn in hooks as far as I can tell.

* I am an experienced React developer but haven't had much opportunity to work with it in the past 2 years.

TFA addresses this: it qualifies by saying learning is good as long as it's useful outside of whatever narrow scope they appear. The real criticism in that section is that hooks (and e.g. gotchas related to things like useEffect, stale closures, etc) are non-transferrable knowledge.

As others have said, I still don't really think it's applicable because learning hooks takes an hour or two, but to try and address that point: I don't really think the knowledge is non-transferable at all.

There's two aspects to learning hooks:

1. Learning the API. This is not a "conceptual" part of learning but rather "this function name does this thing". This is the same with learning any programming API and is almost always non-transferrable (with the minor exception of some open standards, except that varying implementations of them still tend to have quirks).

2. Learning the patterns and concepts around applying that API to problems. As far as I've seen just from TFA examples, they're very widely applicable. Memoization is widespread. Functional style is widespread. The most complex stuff handled by the quoted examples is maintaining state in nested hashtables, which is such a widespread concept that observable/immutable libraries like MobX et al & ImmutableJS et al have been written pretty much focused entirely on this problem space.

I initially had a few, but after making sure they weren't just learning curve exasperations in disguise, I realized they all boil down to that they should've just started out with this and never had any class components.

I often see developers mix up classes and functional components with hooks in abominable ways, and every pitfall to hooks I can find just boils down to improperly brackish OO class model polluted thinking.

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.

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

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.

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 to other systems, like vanilla Javascript is. React is great because it's vanilla Javascript, expressions all the way down, and lifecycle methods, which everyone is used to. Hooks are a new non-vanilla-javascript paradigm with special and sometimes tricky rules. Other than, there's no reason to write React unless you're using hooks, and I wonder what the next major paradigm shift will be. I look back on all our HOCs and function as children and shudder compared to how easy it is with hooks.

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

My mental model of JSX is that it's vanilla Javascript, and it's helped me appreciate trying to write more expressions and less statements. Like JSX isn't getting transformed into some weird different control flow, it's just a nicer way to write the same expression. And DSLs are a good general computer science principle. Hooks don't seem quite as general of a concept to me as a really well thought out DSL that has a minimal surface area but still turns out to be super useful.

Hooks are very similar to applicatives as you’d see them in Haskell, for what it’s worth (it’s where a lot of the rules of hooks come from). They also have some similarity to algebraic effects (as do sagas).

> an absolutely huge departure from vanilla JavaScript

Doesn't it just convert to React.createElement? I wouldn't call it absolutely huge.

By this logic, what could ever be considered "huge" departure? Any new language construct "converts" to something lower level unless that language is a set of assembly instructions. I mean, Elm converts to vanilla JS but few would say it's a small departure from it.

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 to DOM what XAML+WinForms is to win32. I had assumed we were discussing conceptual leap between native and framework-based UI implementations.

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.

The point is that <Component prop={0} /> is equivalent to React.createElement(Component, {prop:0}, []) - it's a static, typed descriptor, and you imported the Component from somewhere because it's just another function/class. There is no such equivalence in magical templates of Angular or Razor - the JSX won't break as long as JavaScript can call functions, and will behave exactly in that way.

Yes, it's a move to declarative code from procedural one, that's right; what's important for my distinction is how is the move done. The question we're answering with React (as opposed to Vue, Angular, Razor...) is not declarative/procedural, but magical/not magical.

P.S. I heard that templates in Angular are not just templates anymore, they're converting them to function calls - I don't know the specifics, last Angular i saw was version 2.

> 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

That's just reductio ad absurdum claim.

JSX is one simple conversion while coffeescript or elm are entire turing-complete languages. It's like claiming a smiley face on the back of a receipt is no different from the Mona Lisa.

Yeah, all of the dynamic parts of JSX are Just Javascript.

You can also look at JSX and know exactly how it will compile to Javascript because it's so simple. (foo && <Component {...props} />) -> (foo && React.createElement(Component, props)).

It really is just React.createElement calls. It just isn't a huge departure.

Meanwhile, what Elm compiles to is very nontrivial. The comparison only makes sense if you never actually looked at what JSX does thus mistake it for something much more complex.

Try it out yourself: https://babeljs.io/repl

"just convert" is in itself a huge departure from plain Javascript (in the sense that you now need a whole transpiler to get anything running at all, vs just running the source code as is)

The JSX is just a bunch of function calls, all the complexity is in React the library - you can do a very light JSX to DOM library with zero of that complexity.

<Foo bar="baz"/> = Foo({ bar: "baz" })

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

Technically, it depends on what babel plugin and configuration you use (e.g. it compiles to `h(Foo, {bar: "baz"})` for a preact setup and to completely different code w/ a Solid.js setup)

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.

I agree with you - so much so that I don’t use source maps to debug stuff. It’s also the same reason I strongly dislike hooks (they aren’t really JS) while at the same time, they solve a problem I very rarely have (shared behavior without shared state).

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.

This argument maps to CSS-in-JS, too. It's a misunderstanding that this pattern would be rejected outright.

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.

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.

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

> I look back on all our HOCs and function as children and shudder compared to how easy it is with hooks.

If by "function as children" you're referring to render props, personally I was really happy to see that short-lived fad die out. I don't think render props made things simpler.

Now if we can admit we never needed Sagas just to do some data fetching maybe we can burn that stalled-out old bandwagon, too :D

(Sagas are a powerful pattern, I'm sure someone here is about to reply about how they're making good use of them. But I'd bet 99% of people using the redux-sagas library could be doing something simpler).

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.

I'm a Redux maintainer, and yes, I keep trying to tell people that 95% of Redux apps don't need sagas. They're a great power tool for those cases when you have truly complex async workflows, but they're complete overkill for basic data fetching behavior.

I wrote about why I chose thunks as the default in our Redux Toolkit package:

https://blog.isquaredsoftware.com/2020/02/blogged-answers-wh...

and our Style Guide docs page specifically recommends using thunks as a default:

https://redux.js.org/style-guide/style-guide#use-thunks-for-...

I had to rescue a codebase that was all-in on sagas by developers that didn't seem to really understand what they were for. It was one of the most difficult and frustrating projects I've ever worked on. Debugging was a total nightmare because bugs were so decoupled from their causes. I'm sure there are cases where, in the right hands, sagas can help solve complex problems but, like redux, they are overused by people that are just following the herd and can create a ton of accidental complexity.

One of the things I love about ClojureScript's Reagent library is that I will never need something like Redux because Clojure has was Redux does "for free." Reactive state management is baked in at the language level.

I've gone through your recommendations and adopted most of them. This one feels really strange though. In the recommendation you say:

> If you have truly complex async workflows that involve things like cancelation, debouncing, running logic after a given action was dispatched, or "background-thread"-type behavior, then consider adding more powerful async middleware like Redux-Saga or Redux-Observable.

Aren't these kind of things necessary for really robust applications? For instance, let's say my app fetches some "posts" list and shows it as a table. I have so many "posts" that I'll do server-side pagination. With a naive thunk, if the user clicks on "page 2" and then quickly on "page 3" it is perfectly possible that she ends in "page 2" (because that request happened to complete after the one for "page 3").

How are we supposed to deal with these things with thunks?

Cancellation is definitely something that is trickier with thunks. We recently added a new `createAsyncThunk` API [0] to our Redux Toolkit package, which has built-in support for signaling some kind of cancellation using an AbortController [1], but how that gets used in relation to your actual async call and how your reducer processes the responses is up to you.

Cancellation, debouncing, and other "thread-like" behaviors are where sagas are truly useful. But, in most cases folks are just trying to do simple AJAX requests for data fetching, and trying to learn how to configure and use sagas just for that is way too much overhead.

[0] https://redux-toolkit.js.org/api/createAsyncThunk

[1] https://redux-toolkit.js.org/api/createAsyncThunk#cancellati...

+1 for being on board with whatever killed render props and a bunch of HOC's.

Mostly like them, but still not sure the canonical way to write update logic comparing prevProps to current props and running something if it changed where there is more than one dependency though. Need to store prev value in state to compare, or best to ignore the exhaustive deps warning and only run when the prop in question changes? Swear I looked all over and couldn't find a good answer.

What's the problem with render props? You need a component to provide values to its unknown children, you either do render props or you need to clone the children injecting them the values. I find render props to be a much more clear pattern than clone. It also works nicely in TypeScript doing the proper type checking. Am I missing something?

Edit: I think I missed the point. Hooks do make providing state to children simpler in a lot of cases. I just don't hate render props that much :)

> the major complaint I have about hooks, which is that it's no longer Javascript

Are you saying that hooks are implemented in a way that needs a compiler (e.g. like CoffeeScript or TypeScript) for them to work? I've always assumed they were implemented using closures or a similar pattern.

It is JavaScript, but it doesn't feel like JavaScript. What looks like a pure function isn't actually, and can do a different thing depending on where and when you run it, all hidden in some magic within the React library.

JS is one of the most un-opinionated, flexible language around, I do not believe there is a one true way™ of doing JS. For example, React and Angular have very different approaches (functional vs OPP) on how to JS.

I do agree that having something do a different thing depending on where and when can be counter-intuitive.

Meaning that instead of using existing JavaScript structures to provide instance state, it's re-implemented in an abstruse way that creates a whole bunch of constraints on your code and new rules to keep in your head at at all times that are react-with-hooks-specific.

If you oppose JSX, then you should doubly oppose Angular Templating language, since that's an entire language construct that gets compiled to JS function calls. Broader point: We need some syntactic sugar on top of JavaScript for writing UIs. JSX is about as simplistic of an abstraction you can get it. It's incredibly easy to reason about its pre and post-compiled syntax. Not the case with other paradigms.

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.

I feel that with class components I have a really good understanding of what is rendering and most importantly, when. componentDidMount, shouldComponentUpdate, PureComponent, etc. With hooks, it's much more magic. And clarity of rendering is literally the one thing I want from React.

We have two projects, one using class components and one using hooks, and working on the class components one is unexciting, straightforward, sometimes repetitious, but never confusing. When writing hooks on the other hand it's constant gotchas; can't do that here, didn't memoize this, can't call that within this, etc. fuzzing until it works as Reacts expects. And then the bloody thing still renders on every frame. Back to the drawing board to figure out the right magic incantation. Probably memoize a few more layers, ugh.

Memoization is getting me too. I end up memoizing everything, which is more verbose than I'd like. Perhaps we're missing some obvious pattern?

Though note that React.memo(Component) gives you the same behavior as React.PureComponent which is what people were tending to default to anyways.

This is how I feel too, and I'm a confused how the reaction to hooks is so overwhelmingly positive. I find it quite strange that we need to set up an eslint rule to make sure our function arguments are correct, and it will automatically fill them out if we don't. And I need to memoize so many things! I feel like I'm not even writing javascript anymore.

This is the most legitimate criticism I've seen in the discussion. Hooks give you more control. 'useEffect' will only re-run when any value in the dependency array is updated. In class syntax, you have 'componentDidUpdate', but that function gets called after any prop or state change. With hooks, there is more granularity. Personally, I've found reasoning about hooks to be a learning curve that was conquerable in about a week. But there is no arguing, it requires you to mentally reason a little bit further than the blunt 'componentDidUpdate'.

It's a bit of a trope by now, but there is a lot of truth in the common argument that if converting your class component to hooks makes it feel more complicated, you probably had subtle bugs in your class component -- usually an edge case you hadn't bothered to handle. The main quirk of hooks is that it makes problems in your components a lot more visible. I don't view this as a bad thing, but I totally get that it's frustrating.

You have my vote for the best criticism of hooks in comments.

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. The developer experience is nice if what you're doing is basic. But if, for example, you're aiming for 100% code coverage, unit testing hooks is an absolute nightmare.

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

I'll see if I can find the link, but I recall seeing some references in the official docs, naming `this` complexity as a key inspiration for looking to hooks as an alternative to stateful classes.

That complexity was largely avoided by using arrow functions.

It's right there in their intro to hooks in the section "Classes confuse both people and machines" [0].

[0] https://reactjs.org/docs/hooks-intro.html#classes-confuse-bo...

That is about a lot more than just 'this' confusion though.

But focusing in on the ‘this’ criticisms highlights the general criticisms. They think ‘this’, or the Class model is a barrier to entry for React.

React is a great framework, and super intuitive on so many fronts, but where it misses, it misses big. To come to the conclusion that the Class model, a pretty predictable pattern, is more a barrier to entry, or a conduit for confusion, is really misguided.

Just take a look how simple functional components can take on a quasi Class-like form with lookup maps for hooks in this particular article. When you advocate for stuff like this, you are injecting the community with effectively bad practices.

The React dev team can not resort to the ‘You probably don’t need ________’ article in perpetuity. At some point, they have to say to themselves - ‘We probably don’t need to add this to the API’.

I agree that the lookup map thing looks like very bad advice. I can't see a reason why you'd do something like that.

On topic, it has been my understanding that the React team is moving away from classes for a number of reasons. Not just because it confuses people (although the pattern seems to create expectations that aren't met due to Javascript's weird 'this' behavior), but also because it doesn't have a good pattern for code reuse (as demonstrated by the lack of mixins that used to be popular in React's createClass syntax) and also because it seems to be a suboptimal pattern for compilers.

That said, I've moved on from class components to function components with hooks and I can't remember the last time I thought something would be easier to implement as a class component, even though it is still an option to do so. But that is, of course, anecdotal.

I was just providing the link.

I am far more confused by hooks than by classes and 'this'.

Also you can't really try to protect JavaScript developers from understanding this. It's a fundamental part of the language.

Disagree. I understand `this`, but I very, very rarely encounter situations where it doesn't mean the same thing as Java's `this`. When you work on a full-React codebase, it just doesn't really happen. We used to have weird `this` behaviour on event handlers, but arrow functions and hooks fixed this.

Not saying it's good or bad, just an observation

Right, but without understanding this one doesn't really understand arrow functions either.

`this.foo = this.foo.bind(this)` and then the new feature of method properties `foo = () => this` vs `foo() { this }` are constant sources of confusion for people who aren't well-established in Javascript/this. Not to mention function() vs arrow functions.

All exist because of the idiosyncrasies of `this` that you may be discounting because of your familiarity and already being over the learning curve that ensnares people daily.

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 logic in components. Then decompose your mega-components into simpler components. This removes all remaining need for reusable logic. If you still have reusable logic inside your component -- this is very rare -- allow some duplication of code, this is better than creating monstrous code that nobody understands.

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-day basis for me, there are still plenty of uses for reusable logic inside of components even after extracting business logic / creating small focused components, especially as it pertains to presentation. A simple example that I use somewhat frequently is a window-size watcher.. a pretty simple hook that watches the window-size, re-renders when it changes (on a debounce), and it provides the current width x height of the window, allowing the component to use those values to calculate some view parameters. With hooks, it's as simple as plopping `const { windowHeight, windowWidth } = useWindowSize()`. Without hooks it generally requires wrapping a component with another.

I've been using hooks basically since they came out and IMO they're way more in tune with React's programming model than class-based components. Even if you create custom hooks for most components, the paradigm still encourages developers to encapsulate related pieces of component logic into their own hook-functions rather than spreading that logic across multiple lifecycle methods. I haven't come across a single situation where I would have preferred a class based component.

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!

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.

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.

I never had scoping issues around `this` in my react code (earlier js libraries, yes), but I still love hooks. I find them more comprehensible and consistent. I love that the API is smaller. I had to fix a number of bugs caused by the life cycle methods when I did a react 15 to 16 upgrade a while back, and it seems unlikely those can crop up with hooks.

A big problem with `this` is it is mutable. Dan Abramov has a nice article[1] explaining why that is a problem and how it leads to subtle bugs that are common in React apps. Hooks eliminate this problem, and I would guess this was one reason they decided to move forward with them.

[1] https://overreacted.io/how-are-function-components-different...

That’s not a problem with “this”, but a self-inflicted problem from React’s chosen model of reusing class instances. It’s a design choice made by them and not a language issue at all.

True, although I did mean my comment in the context of React. Hooks are basically them rolling back this choice.

> Maybe I'm weird, but I never really wrote JS that caused scoping issues, so I never found `this` to be a problem

Either you're weird, or you've been doing JS mostly in the modern era of fat arrow functions, and fat arrow functions have succeeded at reducing the confusion from nested functions each with their own `this`.

Even before arrow functions I just never had much trouble. I had a very consistent way of writing logic. Only ran into scoping issues a few times.

I gotta be honest, I agree with this - `this` was something that bit you once, and you quickly learned to `.bind()` (or use the 3 line polyfill for it...).

I find my older pure JS codebases so, so much easier to go back and remember what was going on than some of the React stuff I've had to interact with in the past 5+ years - and I say this as someone who has written, released, and taught React.

The problem for me is, I think, I'm not sure you can do better than React. You'll either wind up with some complicated beast from hell (Angular) or veer off into performance-benchmark-overvaluing (Svelte).

The problem with 'this' (well, one concern): sometimes you don't have a choice. Suppose you consume a library, where you call a function, passing a function as an argument. Your function's this context can be overwritten, even if you don't desire it to be. I recently ran into this issue when consuming a third party library.

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 don't need to throw out classes or objects to get reuse.

2) React developers do not understand functional programming. I could write an entire essay on this. But it should suffice to say, FUNCTIONS DO NOT HAVE STATE. What React hooks introduce has more in common with dynamic scoping, of older LISPs. It fundamentally breaks lexical scoping, which is incredibly important for understanding code flow. You have to be constantly aware of when it's safe to use certain variables and the implications of using variables in certain scopes now. In 2020!! This is INSANE.

> they did not understand

> they do not understand

> This is insane

This sort of post that asserts that nobody understood or put delicate thought into something is just pompous and lacks intellectual curiosity.

At least respond to their rationale. In doing so, you’ll find that everything is just trade-offs.

btw Dan Abramov is great to follow on twitter. He often responds to criticism and clarifies React decisions and links to good blog posts. If you use twitter it’s a nice way to get polite, bite-sized wisdom about React and Javascript. At the least you’ll realize how much good thought goes into React.

It fares well next to all the other comments saying this article is “pure whining”.

RE: 1) "it is that components cannot reuse logic" - +1 to this - recently I re-watched original hooks talk by Dan Abramov and was not able to finish it with conclusion different than "you guys really fix issues you invented before". Class-based components and reusability of logic is something that existed years before React, and probably will exist years after React. Even this concept of Dependency Injection and Services that Angular is still on proves that there-are-solutions. There are solutions for reusing logic between classes. Thing that bothers me the most is not that there's something wrong with fixing your own issues, but the fact that developers outside React Core Team start to think that "well, you cannot reuse logic between components".

Angular does not have a solution for this as far as I know. It's not about re-using logic. It's about re-using reactive logic that ties in to your component's lifecycle.

I'd argue Angular does, in the form of RxJS.

The "idea" that react hooks try to implement is very common in FP languages though. It has a lot of parallels with extensible effects; which is a pure, functional embedding of the idea of hooks

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 have yet to encounter anything like it in React, and it'd be surprising in any case to encounter dynamic scope in Javascript, a language which does not even support it. The closest I can come to understanding what you must mean here is to think you're very confused about how React props work, but that doesn't seem likely either - I can hardly imagine someone having such an evidently strongly held opinion about something, and having that opinion turn out to be based on a fundamental misunderstanding of the subject.

Would you mind explaining in some more detail the issues you see with React functional components? You mention having an essay's worth of material, and while that's probably more than we need to support a discussion, perhaps you'd be so good as to boil it down to a few points with a little more substance to them than "React developers don't know what they're doing" and "this is insane".

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

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

> But it should suffice to say, FUNCTIONS DO NOT HAVE STATE

It's funny you say that: useState is the same model functional languages use to handle mutability.

https://docs.racket-lang.org/reference/boxes.html

I think this is mostly a disagreement around terminology.

The GP is referring to purely functional languages like Haskell, where functions don’t have state and are referentially transparent. In Haskell, useState would have to use a monad.

Racket (and Lisp in general) has mutable state so doesn’t guarantee referential transparency. You can definitely write pure functions, and that’s good style in many contexts, but it’s not required or enforced.

I personally agree with the GP, and assume “functional programming” to mean pure functional programming. It’s common to use an FP style in non-pure languages, but I think this is FP if and only if you completely avoid state.

One way or another it's fine to consider methods that explicitly use state as 'not functions'. This is the mathematical definition after all.

That definition leads to the conclusion that hooks aren't functions, which seems fine honestly. I mean, why insist on using them as functions when they're clearly not? Their syntax is a bit unfortunate, as is the fact that you're not forced to declare them immediately at the start of your function, which looks like it would have cleared up many of the potential problems. Either way their use case is clear, using hooks seems to basically dynamically declare a state monad for that particular function (hence why I'd recommend doing this upfront).

I'm not a React programmer though, so take this with a grain of salt.

> how silly it is that components cannot reuse logic

It may be that your component is too complicated. Components should only have UI code. First move business logic out of the component, into your model layer, and make it reusable there. This step will eliminate most of the need to reuse logic in components. If you still have logic inside your component that you want to reuse consider restructuring your component into multiple simpler components.

> React developers do not understand functional programming

As some sibling comments note, this is not a fair conclusion to draw. And not that it disproves your statement, but Reacts original creator Jordan Walke wrote the first React prototype in SML. Not understanding functional programming is not on the list of things I would ascribe to him. He's a smart guy.

On a slightly different note, I'd recommend anyone try out Reason. It's slowly maturing and can be a real joy, at least compared to JS/TS.

Do you have any good resources for getting started with Reason? I've tried a couple times, but it seems like there's a schism between https://reasonml.github.io/ and https://reasonml.org/

Yeah, I'm not really plugged into the community that well but I think reasonml.org is the long term plan and that some sort of transition might be going on? I've mostly used reasonml.github.io and Bucklescript docs, but lately I've started using the Discord channel and it's very welcoming, friendly and helpful!

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.

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.

When saying that "functions do not have state" without mentioning monads and encoding effects in type systems, it doesn't sound like you have enough experience with functional programming to assert your second claim.

I've been using hooks full-time for the last year or so in a _very large_ React code base (one of the largest in the world). None of these so-called problems are real in my experience.

The first point is just whining about not wanting to learn new things -- we've on-boarded many new people onto our team in this time, and hook-based code is the easiest to understand. It's the old class-based components that are hard, and the most experienced team members work there usually to rewrite them as functional components.

The second point is only sort of true. They can interact with class-based components in a parent-child relationship. That's enough to gradually migrate your application towards hooks: any time you want to make significant changes to a component, rewrite it.

The third point is not a problem in my experience. Yes, we have rewritten some of our internal libraries as a direct result of hooks being available, not because the old ones didn't work but because we now had the tools to create a _much better API_ and took advantage of it.

The fourth point makes no sense to me. If you need to use conditions like that do something different, e.g. put the different cases ("a" vs "b") in different child components and render the appropriate one. Any programming paradigm has rules around it, and this is no different.

My response to the fifth point is "don't depend on control flow". You should be robust to evaluation order so it doesn't matter the exact order that React executes your code. If you have a execution order dependency in your code it will be highly brittle.

In my experience people abuse react components by making them too big with too much functionality. If you have a bunch of hooks tied together in a brittle way, thats not the hooks's fault. It's a good sign that you need to refactor your component into smaller sub components or move functionality out of components all together into redux or some other non UI related code. A big component with lots of logic will always be a liability whether it's hooks or classes because it will mix presentation with business logic and will rarely be well tested.

It's unreal that in React I have to deal with occasional infinite loops now because of hooks. Sure, React catches the loop cycle so things don't totally freeze but I don't recall ever having to deal with this before them. Weird, unexpected reference issues, missing dependency accidents requiring linters to prevent, strange programming patterns, a team member having to write a terrifying novel like https://overreacted.io/a-complete-guide-to-useeffect/ for something that was never really a problem before. The list goes on and on.

The problem before was that your class component was not updating correctly and rendering stale & out of sync data. If it were updating correctly, it would have had the same infinite loop problems.

Exactly this. Class components let you cheat and easily write components that were broken if a prop was unexpectedly updated. Hooks will surface this immediately.

You could easily wind up with an infinite loop without hooks (for example, by calling `setState` in `componentDidUpdate`).

That would be trivial to spot. Not the case with hooks.

It's trivial to spot with hooks.

This is definitely not the case. I’ve seen enough class components with complicated componentDidUpdate methods. The method would then be broken up into multiple other smaller methods (or to re-use some logic in didMount and didUpdate)

A few iterations later and you have setState peppered throughout your component.

More often then not though I’ve seen a lot of class components that would just fail to update when certain props change. It’s much harder to miss these cases with hooks.

>It's unreal that in React I have to deal with occasional infinite loops now because of hooks. Sure, React catches the loop cycle so things don't totally freeze but I don't recall ever having to deal with this before them ... missing dependency accidents requiring linters to prevent

Infinite loops and missing dependencies are/were issues with `componentDidUpdate`/`componentWillUpdate` and `componentDidMount` as well, though. On the plus side, you now have a linter which can both point out these errors and automatically fix them for you. I agree that the whole thing is a bit leaky and dumb though, but there's no way to fix that without introducing some sort of compilation/optimization step and afaik the React guys aren't really considering that at the moment.

>Weird, unexpected reference issues

Not sure I've run into this before. Do you have any examples?

>strange programming patterns, a team member having to write a terrifying novel

The first bit seems like personal preference or something, not sure what you're referring to as strange. The `useEffect` novel exists because a ton of people had built up their (incorrect) mental model of how React works with lifecycle methods and were making mistakes or running into unexpected behaviour because they assumed `useEffect` was the exact same thing as `componentDidMount`.

Reference issues:

1) Needing an advanced understanding of closures. Not always, but sometimes. That "sometimes" is often unintuitive, requiring weird solutions like useRef. Good luck beginners.

2) Things like updating reducer state by using a spread object, which creates a new object which can then send a system haywire. Seems fine, and is mostly fine in most cases, but hey, oftentimes not fine, and why that's so is not always clear. So then there's memoization, and useCallback and all of these safety checks -- each with their own dependencies array that need to be checked. It's really too much tbh. There are lots of solutions out there that use proxies to check this stuff; React should have baked that into the core and completely removed that responsibility from the user unless they wanted to opt-in micromanage performance of their code.

> Things like updating reducer state by using a spread object, which creates a new object which can then send a system haywire

This is what you should be doing and not doing this seems more likely to cause problems. Do you have an example?

ClojureScript user here, with a big SaaS app using React, developed over the last 4 years or so, using the excellent Rum library, https://github.com/tonsky/rum.

It seems to me that React Hooks, like so many things in the JavaScript world, solve a problem I do not have. To this day, despite being a heavy user of React, I don't even fully know what they do. I've read the "Motivation" section of the React Hooks Intro, and it seems that I have none of the problems they describe: I can (and do) easily add stateful logic via Rum mixins, and that logic is reusable across components. Also thanks to Rum mixins, complex logic is understandable and does not get all thrown into a single 'componentDidMount' function. As to "Classes confuse both people and machines", I find it hard to relate to this problem, because I don't really see any classes. I work with components that have a render function and mixins, and if you don't use any mixins, a component looks just like a function.

This tends to be a recurring theme: every once in a while I read an article about JavaScript and React, and I can't even relate to the problems, because they do not exist in my world. Another good example is hints on how to optimize apps to avoid excessive re-rendering, something I get for free with ClojureScript and immutable data structures (you can always quickly tell if two data structures are equal and avoid rendering).

You've solved the problem that hooks solve by using Rum mixins instead, and you're confused why you don't need hooks?

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 really discouraging to see people put Clojure(Script) and associated libs on a pedestal, because it removes any nuance from the discussion and makes people think that the Clojure community are a bunch of holier-than-thou zealots.

FWIW, I was (am still) super excited about Hooks and have posted a lot of things critiquing ClojureScript React wrappers in the past, but I recognize now that they are making tradeoffs that ultimately are what the authors think are in the best interest of their user base. It would really be great if you (and everyone else) would enter these discussions with the same assumption.

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

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.

Yeah, that's why rum recently added support for hooks...

Rum and Reagent added support for hooks mainly for compatibility. Never needed them before.

People talk about the 'good old days' of jquery. I do think it was easier to be a web developer in those days because there weren't as many levels of abstraction. It was just your simple text editor, html and js script, that's it. And you were directly changing the DOM. But writing jQuery for complicated apps can get out of control very fast. I do not miss querying classes on an element to figure out what to do next. Nowadays I meet 'React Developers' who didn't know that you can do document.querySelector(...). They tell me without batting an eye that React makes websites faster.. and that it is faster than plain javascript. And before anyone tells me that it can make things faster through DOM diffing or what have you -- you are wrong. Situationally React could be faster than poorly written js, but in most cases it won't be and that is not its point. It doesn't magically imbue your web application with hyper speed. Quite the opposite! Its like all these layers of node, npm, React, Hooks crud built up and there are actually people junior enough that their only exposure to webdev is through this morass -- and that is sad. Not because these tools/frameworks are bad, but because web dev can be so simple and easy and they are robbed of having that in their back pocket, as a proper foundation.

I learned about Crank today:

https://crank.js.org/blog/introducing-crank

Crank itself is interesting, but what's relevant here is the broader critique of React there.

This is really compelling - thanks for linking it. Is there a downside here? Has React responded at all? I don’t hate hooks, but using async + generators like this looks so obviously better and more intuitive here; like such a clearly great, simple idea that I’m embarrassed I didn’t ever think of it myself.

There was a lot of discussion in the Crank thread. Essentially, concurrent mode is the primary goal.

https://news.ycombinator.com/item?id=22903967

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 Hooks don't have the same sort of structure and can be difficult to understand at a glance.

One of my gripes with Hooks is that listening for async state updates requires more code/complexity than w/classes. In a traditional class component, you can add a second, optional argument as a callback which is called when the state has updated:

  setState({ myState: 'newValue' }, () => { this.doSomething(); });

With Hooks, that doesn't apply. The useState "set" function doesn't have a similar argument.

  setMyState('newState');

Instead, you need to use 'useEffect' with an optional argument:

  useEffect(() => { doSomething(); }, [myState]);

This leads to potentially having many "useEffects" scattered throughout the component.

That said, this is just my experience with Hooks after a few months of working with them. It's entirely possible that I just haven't had enough experience with them yet.

Having a separate useEffect certainly scatters your code, but it helps prevents bugs that cause your states/effects to go out of sync.

If you use a callback on setState in order to listen for async state updates like

  setState({ myState: 'newValue' }, () => { this.doSomething(); });

then a week later, when you add some different code calling setState({ myState: 'newValue' }) somewhere else without remembering to add the callback, your callback won't run! Callbacks kind of break the declarative/reactive model.

Components with lots of hooks in them remind me of spreadsheets. I find myself tracing from one hook dependency array to the next, trying to follow the logic.

> With class components, my state/props are clearly defined within the constructor and/or PropTypes.

What do you mean? PropTypes work just as well with functional components as they do with class components.

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?

Hooks are great for simple use cases like `useState`, `useContext`, some uses of `useRef`, etc. and can make the code easier to read and reason about (while conveniently working very well with TypeScript).

The rules do start to get really tricky though with complex use cases of `useEffect` and multiple levels of nested hooks, and implementation problems are often not easy to spot or debug.

Dan Abramov has written a lot about the philosophy of hooks[0] at his site overreacted[1], I'd love to see a 'retrospective' write-up from him or another React team member about what they think the success and failures of hooks have been so far and if there are any changes planned for the future!

[0]: https://overreacted.io/why-isnt-x-a-hook/, https://overreacted.io/algebraic-effects-for-the-rest-of-us/, https://overreacted.io/a-complete-guide-to-useeffect/

[1]: https://overreacted.io/

It's a unfortunate that he doesn't include the equivalent class-based implementations of his logging quiz. Event lifecycles notoriously obscure order of execution, so I'm not sure the alternative is any clearer -- especially not with contrived examples. In my experience with both hooks and classes:

- Hooks require substantially less boilerplate than classes.

- Rendering optimization problems with hooks tend to take more time to identify and to fix.

There are other pros/cons, but these are the ones that affect my work most frequently.

All of this reads akin to someone criticizing an apple for not being an orange. Every point is an intentional design decision. Learning new things is necessary, leaving class syntax behind was a choice, and imposing limits on (controlling) application design is the point of libraries.

The team is pushing a functional declarative pipe method of building UI applications where things are built using a straight-line series of composed functional transformations. Personally, I think supporting this method with the hooks model of handling side effects is an improvement over everything else that exists in "roll your own" UI library land. I find these style libraries more enjoyable to build with, more expressive, and better suited to building things where you need finer grain control than template style libraries like Vue, which provide a stronger degree of predictability and ease of immediate use.

That's the thing -- it's a balance. Hooks add a nicely considered and balanced degree of order to the otherwise intentionally uncontrolled-so-you-can-do-the-controlling programming model of React. React identifies as the advanced lego set with the smaller more numerous blocks that you can build the cooler stuff with, and as such will always have a certain threshold of complexity.

You didn’t actually counter any of the authors’ points.

This wonderful functional declarative pipe method of building UI applications where things are built using a straight-line series of composed functional transformations can really suck in real world applications as he tries to demonstrate. Anyone building with hooks now can relate to hooks bringing disorder to the codebase.

Has your experience been different? How did you avoid the pitfalls mentioned?

Well #2 isn't really a pitfall, for starters. I have a new feature that solved a problem I had but I can't use it in the code I wrote before I had it without refactoring? I don't think that critique really has anything to do with Hooks, just software development. It's also basically a rephrasing of #3.

Unless you work on anything beyond a small codebase, and suddenly half of your code cannot be composed with the other.

1. It's not more stuff to learn, it's different stuff to learn, arguably less. Learning Components is not a prerequisite for learning Hooks. Or perhaps I missed the memo, as I've built an app using Hooks, and still haven't need to learn what 'componentWillMount' is supposed to do.

2. Don't mix Components and Hooks.

3. Agreed, change is hard. It's also the only way to avoid stagnation. In the long term, change wins. Or else we'd be programming in JS1995.

4. Insufficient example. What is the business case for a memoized hook returning hooks? Perhaps there is a simpler design, can't comment.

5. There is no global control flow. There is only per function component control flow, which proceeds from top to bottom. Possibly preempted by a hook/hookfn execution, if my early learning curve is to be believed. Which shouldn't matter if one is thinking in terms of 'pure functions returning jsx', as preempted functions do not return, thus have no observable effect.

Tip: Only change hook state from event handlers, never from render function code.

> In the long term, change wins. Or else we'd be programming in JS1995.

Change for the sake of change is not a sound argument.

The thing about hooks is they don't enable a single thing we couldn't already do with HOCs. They are also much harder to read, because stateful logic is now just sprinkled around your render method rather than being isolated to places you know to look for it. I won't be using hooks ever, as far as I'm concerned.

Of course.

* "A Critique of React Hooks"

* "A Critique of the Change Costs Induced by React Hooks".

Objections to React Hooks are stronger if they don't invoke change costs as the primary three concerns.

He/she gave a very valid critique of state being jammed into your render method, vs state being handled in a predictable pattern in Class components.

And lastly, let’s not minimize change-cost. In the real world, it’s a cost. We’re all willing to pay it if it’s necessary, or affordable, but not because someone showed up and said ‘change please’.

Unless you learnt react from non-official sources, you can't avoid learning components because they teach them first.

You'd be surprised. The only deeper dive into Components is https://reactjs.org/docs/state-and-lifecycle.html of the "Main Concepts" section, which I skipped in favor of https://reactjs.org/docs/hooks-state.html of the "Hooks" section. Haven't got to "Advanced" yet, hope to stay clear of that.

The React team is working on rewriting the docs to focus on function components and hooks first, as of this quarter:

https://www.reddit.com/r/reactjs/comments/g2pda4/functional_...

> In the long term, change wins

Yes, but how long is long term?

jQuery hasn't radically changed its methodology in almost 15 years.

> imposing limits on (controlling) application design is the point of libraries

That's the point of _frameworks_. It's very ironic to see this being said in defense of React, given that its original appeal was precisely the opposite stance (i.e. React was "only the v in mvc", in response to the notion that frameworks of the time were imposing).

I was skeptical towards hooks when it was first introduced. I was hesitant to use it. Then, I used it for a few components in my projects. I realized how much simpler my code looked, and migrated completely to hooks. No regrets.

I am disappointed with the React team’s decision to push functional components and hooks as the standard way of working with React. Not sure if the reason is to make React more approachable to newcomers or not, but in my experience leveraging the power of the component lifecycle through class components and decorators is the most fool-proof way to build and maintain large applications. Particularly leveraging shouldCompomentUpdate for performance and componentDidMount/componentsWillUnmount for registering and disposing of component dependencies is very easy to reason about and scale.

It's a different way to do things. You can still use Class based components to your heart's content.

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 various lifecycle methods.

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

My take away from hooks is that it is pushing toward making your components simpler. One of the gotchas of hooks is that it kind of "lies" in the way it looks. Take useRef or useState for example. These things are only defined one time even though the are declared in such a way to look like they are defined over and over again each render. They are actually key lookups under the hood. This was a main point of confusion for me initially and I'm sure I'll find out more that I assumed incorrectly as I go. Auto-magic sometimes is confusing to me.

They behave like class property & method declarations. But scattered about in a function and looked up by order rather than name. This is exciting and not considered redundant and obviously a bad idea, for some reason.

Hooks are magic with new rules that are different from regular JavaScript. They don't follow the regular flow you'd expect it would. Requires devs to think a lot about hooks to make sure something is messing them up. Also needing eslint to make sure your code is ok, is a boy flakey.

Hooks it's like learning a new language pretty much, which is only useful for react. I'm using them because of lack of better things.

Once you understand that function components aren't simple, contained functions but rather components that exist in a parent scope (React) and that React actively manages them, it's not magic at all. Also, you don't need ESLint; the rules are pretty simple.

Overall I think hooks are a fine addition to the React toolbox. But I think they are very easy to overuse and the complexity of hooks seems to increase exponentially. I've been involved in two code bases now where hooks are just everywhere and they were both an absolute nightmare. But I've also been involved in code bases where hooks are used more sparingly, about on par with when HoCs were used, and it's rather pleasant. In general, the more "dumb" components your app has, the more manageable it seems to be overall.

My biggest worry with React is that it has restless developers with idle hands.

I have (a lot of) component code that will never be converted to hooks. Can I rely on you not to flake out and pull an Angular on me?

> My biggest worry with React is that it has restless developers with idle hands.

That’s exactly what I take hooks as a sign of. I read the papers and the code when they came out. I still don’t get why they exist except to provide churn to work on. A half-reimplementation of objects with a super weird syntax in a language that already has objects seems like misguided make-work on a project that’s already basically “done” except for the boring, non-flashy work of maintenance and subtler improvements.

I personally don't use hooks (or functional components) at all, but recently read this post from Dan Abramov about algebraic effects which makes a point (among others) the hook mechanism is a pretty simple way to implement state/effects/context in a language with algebraic effects.

https://overreacted.io/algebraic-effects-for-the-rest-of-us/

Yay, just what we all needed to help us write clean, maintainable code... algebraic effects??

Honestly? Maybe it is, maybe it isn't. Imagine replacing "algebraic effects" in your question with "exceptions" - theres no clear answer. What do you think?

Ah, I used to be on this side of the fence. Now I've learned to love hooks, and aced the test (except for the last, extra BS, question).

Now the two issues I have with hooks still nag me in the back of my head, but are easy to get over:

- `useCallback` still makes new function references that wouldn't happen in class-based components. as someone who starts out with `class MyComponent extends React.Purecomponent`, that bugged me.

- easily access old props after updating. I built my components with something like `useEffect`, where mounting was considered "changing props from null to _something_", and updating was like normal:

  class MyComponent extends React.Component {
    componentDidMount = () => {
      this.handlePropsChange(null, null)
    }

    componentDidUpdate = (oldProps, oldState) => {
      this.handlePropsChange(oldProps, oldState)
    }

    handlePropsChange = (oldProps, oldState) => {
      if (didPropChange('userId', oldProps, this.props) {
        // now we know that props.userId changed, but also have access to `oldProps.userId` in case there's any cleanup that needs to happen.
      }
    }
  }

I know this is possible with functional components / hooks, but it was nice to get this stuff "for free".

React is great at rendering data. It should've stopped there.

After using `ember` and the wonderful `ember_data` at $PREVIOUS_FIRM, I wholeheartedly agree. React is good for what it's good for, but the community sadly did not stop there.

JavaScript is great at small-scale manipulation of DOM elements in response to user events. It should've stopped there.

IMAO hooks are just a dirty hack, but sold very well. Internally in React the state of a hook is being kept and updated when you call the set function, kinda similar to vtables and context in OOP. There is no other way to do this AFAIK. It only mimics functional programming, and that's why you see the restrictions about hooks, you cannot use them outside React, cannot nest, etc..

> The problem with learning about hooks is that they're not generally applicable knowledge about computing or programming.

That's true of the hooks API specifically, but not true of the underlying abstraction. Hooks are (informally) algebraic effects - one of the coolest and most general abstractions for inspecting and manipulating a program's control flow [1, 2]. Algebraic effects are still somewhat niche and most programmers haven't encountered them in name or in practice, so in that regard, hooks are actually one of the fun cases when learning a new API is mind expanding.

[1] https://github.com/ocamllabs/ocaml-effects-tutorial#1-algebr...

[2] https://overreacted.io/algebraic-effects-for-the-rest-of-us/

There's yet another valuable hooks critique that I recommend you to read - https://typeofweb.com/wady-react-hooks/ (Use Google Translate to convert Polish to English)

Hahah, this is good.

> React, like socialism, perfectly solves the problems that it created.

I mean, I got full marks on the quiz in the article. I had to think about the code, but no more than if the same had been implemented as classes. I have been using React for a very long time though, but the areas where execution order can be confusing aren't a problem new to hooks.

One criticism of the article is that it seems to argue that you lose the ability to provide HOC (and probably render-prop) APIs if you adopt hooks in your library. But it's fairly easy to automatically turn those types of hooks into HOCs, so it actually makes sense to have the hooks API be the primary one. You can't really do it the other way around, i.e. turn a HOC into a hook.

Good critique. I agree about control flow and memoization. I tend to run into issues every now and then with memoization and hook "dependencies", but I'm getting better at it.

I think 1, 2 and 3 aren't really great arguments. There's always more to learn, and it seems that class components are on the way out, and are around mostly due to backwards compatibility. But it is true that a lot of legacy code uses them. I wish they'd have started with functional components, but I can't blame the team for not figuring out all of the details in advance.

I'm curious what others think. Thanks!

Feels like the author is someone who really sunk into the composed higher order component style of writing React. As someone who has coworkers who loved spreading logic into 'composable HoC' that only end up being reused 1-2x, I welcome hooks.

A single component wrapped by 3-4 HoC that each do trivial tasks always felt like mental strain rather than a helpful abstraction. My favorite was HoC's that added class component functionality to function components... just use a class.

Hooks are nothing new, it's just repackaging of

https://github.com/dominictarr/observable https://github.com/adamhaile/S

Mobx and Vue use the same technique for running computeds.

As does Solid and Sinuous, etc...

Hooks are much more a reimplementation of the component lifecycle; receiving a change stream is only one of the use cases and has very little resemblance to observables, except that they trigger a re-render “automatically”.

A lot of times I just use a simple React class. The author’s lookup map to return a lookup of other hooks, yikes. A class component would probably solve that in a more predictable way.

Don’t feel dirty for doing things simply. If your functional component has entire lookup maps for hooks, it’s probably too complicated as a standalone functional component to drop hooks in.

It's hard to reason about without an actual real-life use case, but the lookup thing he's doing looks extremely convoluted to me.

Agree, I don’t know what is going on there but it sure smells like something you shouldn’t need to do.

Right, I'd be curious to know a lot more details of the real-life use case that inspired that. My gut feeling says that there's maybe a state machine of some sort which could possibly be split into a sequence or maybe hierarchy of smaller components, but it's hard to tell specifically what the alternative might be without more details on why they thought a lookup table might be useful.

Once you start using Context everything has to become a hook to be able to consume it, I bet that’s what’s goin on there.

From what I've learned using them, hooks are a tool like anything else—pushing one method as "the" way means that you make a lot of poor engineering decisions.

Hooks are like a screwdriver; great for simple stuff when you want to reduce code overhead.

Sometimes you need a power drill, though, and classes and the old-school lifecycle functions are wonderful for that.

I've read about Hooks for awhile, but they still confuse me. Maybe it's largely because I haven't experienced any of the pain points that are described as the motivation for their development, but I've used a number of state-management libraries that handle state.

Just as one example, in a lot of posts and commentary I've seen, is that hooks are replacements for both HoCs and render props.

Admittedly, I haven't yet tried to do any actual development with hooks, but I can't even figure out how to solve the problem in the example in docs for HoCs[0].

Do you pass in a hook as a prop? That doesn't seem wise. A custom hook for each data source still has the same code duplication.

The docs talk a lot about how to build individual components using hooks, but very little about tying them together.

[0]: https://reactjs.org/docs/higher-order-components.html

Hooks solve a couple different problems:

- Giving function components the ability to have internal state and trigger side effects, giving them the same capabilities as class components have had

- Reusing logic across components

I talked about the progress from mixins to HOCs to render props to hooks in a talk at ReactBoston last year [0], which had an example of tracking mouse coordinates using all four approaches. In that sense, yes, they do replace the other techniques as a way to reuse logic.

You call them inside of your function components, like this:

    function MyComponent() {
        const [counter, setCounter] = useState(0);
        const {x, y} = useMousePosition();

        // rest of the rendering logic here
    }

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

> so much to learn

it's almost like software development is a highly skilled technical profession that takes years to master?

This is why I avoid hooks. I design my components to use state and I find hooks to not fit well in my applications.

> The problem with learning about hooks is that they're not generally applicable knowledge about computing or programming. They're a React-specific thing. In 5-10 years when you're programming something completely different your knowledge of hooks will be completely obsolete.

don’t tell him about SwiftUI

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-renders. Unfortunately, that component used multiple hooks, and the only way I was able to isolate the problem was by binary-searching, deleting hooks until the re-renders stopped.

Anyone have better ways of dealing with this?

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.

Interesting to finally see some criticism about hooks.

The biggest problem I have with Hooks is readability. IMO, functional components with hooks are harder to reason about since they obfuscate logic in a weird react-specific contract. Class components have a much simpler, contract and syntax. They also felt much more natural since they picked up on familiar concepts of JavaScript, albeit with a couple of drawbacks. I get the advantages of hooks, but in a way, at least to me it seems like they, at substantial cost, solve a problem which I barely ever encountered, even after building react apps for many years.

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/adamhaile/S

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

Is `more stuff to learn` seriously a critique? I mean if you want to stop learning stuff then maybe, go live in your own little bubble.

The other criticisms seem a little bit like someone who doesn't understand how hooks works criticizing how hooks work because he doesn't understand how hooks work. Perhaps, he doesn't understand how hooks work because he doesn't want to learn more stuff?

My only issue with Hooks has been that they are not inputs into the component. It's a step in the right direction of making React more functional I would just preferred less magic, personally.

  function Component(props, { useState, useContext }) { ... }

Of course that would break backwards compatibility with the old 2nd argument being context, so I get why they did it.

That's not the only problem with your approach. It is extremely common to use the output of one hook in the input of another, and that's only possible if the hooks exist in the function body.

I don't really understand how this approach breaks what you are describing.

All I'm saying is that instead of hooks API being imported from React at global scope it could be provided as inputs into the components directly. They would still exist in the function body as you put it.

Oh, I thought you meant that the hooks would be called there, which was one of the many alternative proposals made after hooks were announced.

In any case, it still wouldn't work because hooks are composable. You can create your own custom hooks outside of components which can be used as if it was one of the primitive hooks. That's not possible if the primitive hooks can't be accessed outside the component scope, unless they're passed in as parameters every time the custom hook is called (and that would be a right pain in the backside).

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.

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.

One thing that baffles me is that no one has brought up that hooks don't have an obvious context.

For instance, if I have a single app and component, and use a hook, I understand that the hook and app have some sort of implicit connection.

But what happens when I have two distinct react apps on a page - does that break the ordering that hooks require? How does a hook have any affinity to the app, or does that even matter?

I'm sure looking at the code will cause a "oh, I get it" moment, but that doesn't mean it's obvious to anyone just picking up hooks.

Honestly, I think hooks are fine, but I'd almost prefer a signature like `const MyComponent = (props, { ...hooksHere })` so there's at least a false affinity between the application and the component.

> hooks don't have an obvious context.

I mean, that's the whole point of hooks... they get the context of whatever host function scope they are in. That's why the 'reusable logic' spiel. So if you create a useLocalStorage hook, for example, you can then plug it into any function component and it will use. It's as if each function was an invisible class, with an invisible this.state

The ordering question is literally just about how you call them within a single specific component. That component can then be used as many times as you want, in as many apps as you want.

In other words, this is not legal:

    const [stateA, setStateA] = useState(false);

    if(stateA) {
        const [stateB, setStateB] = useState(42);
    }

Call as many hooks as you want, in whatever sequence you want. Just make sure all the calls are at the top level of that function component, and that you don't somehow change the sequence of those from one render pass to the next.

As for how they work, React already has metadata that describes each component in the tree. There's a specific field in those metadata objects that gets used for tracking internal component state, and for function components, that field stores an array / linked list of the hook calls you've made and their last saved results.

See these resources for more explanations on how hooks are implemented:

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

I never got into React, but seeing it compared to Svelte I find it hilariously convoluted. Hooks make it even worse.

I don't think this is a great critique, simply because the pain I've encountered using them isn't mentioned here. The incompatibility with class components is what it is, they're different programming paradigms that you have to choose between. If your library leaned heavily into HOCs, that was an unfortunate choice and I'd recommend making a new library because HOCs were always unwieldy and had problems with composition. Nothing to do with functional components or hooks really, just a very heavy pattern that can typically be done better with another approach like render props.

I guess I see a lot of this as evolutionary. It's unfortunate that there has been so much change, and the timing might not be great for some projects, but I would not prefer a world where I was still writing and using HOCs and class components.

In my day job I work on a pretty old (in React years) project, and we haven't had trouble writing new code in a functional + hooks style. Still plenty of class components abound.

The universe is stateful; no matter how hard FP zealots try to abstract that out of code, they will never change this fundamental fact.

FP does not do that.

First of all, there is stateful code and then there is effectful code. It sounds like you are talking about the second, not the first. You can have tons of state and remain mathematically pure.

Where people get hung up is effectful code, or mutable state. Even one of the more hardcore FP languages, Haskell, does not try to abstract that out. Instead it embraces it fully by giving constructs in the language to describe and control effects! This is far more powerful than straight up imperative languages. If anything, writing mutable, effectful code is more powerful in Haskell than in C/C++.

Where Haskell gets difficult is when writing effectful code that interacts with external C libraries and the OS. But this has nothing to do with purity, state, or effects. It really only has to do with the fact that it is designed to have lazy evaluation by default. Which itself has a lot of advantages, but it makes this interaction more difficult as code does not execute in the same order as you write it.

You may find that languages such as OCaml, which are fully functional and have strict evaluation are a joy to work with.

The universe is also highly concurrent and probabilistic, but that doesn't mean we need to design our programming languages that way.

Nonsense. These are all just techniques for modeling reality, not reality itself.

You could model the universe just as accurately as a stateless function of time as you could as a stateful entity that moves through time.

The further you get from the true representation of the thing you’re trying to model, the more difficult reasoning about it becomes. I’m all for abstractions that result in a net positive... I simply believe that FP is less about improving computing and more about ego.

Reply on news.ycombinator.com