A Critique of React Hooks(dillonshook.com) |
A Critique of React Hooks(dillonshook.com) |
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.
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.
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/
> React, like socialism, perfectly solves the problems that it created.
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.
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!
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.
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...
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.
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.
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.
- 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
}
it's almost like software development is a highly skilled technical profession that takes years to master?
don’t tell him about SwiftUI
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?
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.
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'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...
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?
function Component(props, { useState, useContext }) { ... }
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.
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.
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.
In other words, this is not legal:
const [stateA, setStateA] = useState(false);
if(stateA) {
const [stateB, setStateB] = useState(42);
}
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 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
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.
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).
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.
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.
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.
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.
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.
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?
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.
Smaller function components and then adding state with `useState` has simplified my code.
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.
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
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.
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.
- 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 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.
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.
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).
https://crank.js.org/blog/introducing-crank
Crank itself is interesting, but what's relevant here is the broader critique of React there.
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(); });
setMyState('newState');
useEffect(() => { doSomething(); }, [myState]);
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.
If you use a callback on setState in order to listen for async state updates like
setState({ myState: 'newValue' }, () => { this.doSomething(); });
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/
- 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.
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.
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.
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?
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.
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?
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.
https://overreacted.io/algebraic-effects-for-the-rest-of-us/
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'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!)
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.
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...
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.
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
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.
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.
I wonder what about generator functions?
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.
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
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.
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 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-...
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.
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 :)
Suppose you replace:
const [count, setCount] = useState(0);
const [count, setCount] = this.useState("count", 0);
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.
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.
Doesn't it just convert to React.createElement? I wouldn't call it absolutely huge.
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.
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.
[1] https://overreacted.io/how-are-function-components-different...
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`.
> 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.
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.
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".
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...
It's funny you say that: useState is the same model functional languages use to handle mutability.
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.
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.
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.
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.
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`.
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.
What do you mean? PropTypes work just as well with functional components as they do with class components.
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 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?
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.
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).
It works for arbitrary complex cases.
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...
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.
"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.
I'd be surprised if generators didn't come into React at one point or another
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.
I do agree that having something do a different thing depending on where and when can be counter-intuitive.
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).
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.
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.
This is what you should be doing and not doing this seems more likely to cause problems. Do you have an example?
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.
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.
It's interesting. Everything is from scratch. No depa what so ever.
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...
> 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, 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...
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.
(apart from compatibility with other libraries that use them)
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.
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.
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) :
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.
- 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:
(also, "if you know JavaScript you know JSX" is objectively untrue! There are plenty of JS developers that don't work with JSX)
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.
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!
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".
these links might help explain
https://medium.com/@ryardley/react-hooks-not-magic-just-arra...
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.
[0] https://reactjs.org/docs/hooks-intro.html#classes-confuse-bo...
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.
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’.
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.
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
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.
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.
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.
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.
* "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.
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’.
Yes, but how long is long term?
jQuery hasn't radically changed its methodology in almost 15 years.
https://www.reddit.com/r/reactjs/comments/g2pda4/functional_...
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.
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.
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.
Not saying it's good or bad, just an observation
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?
> 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.