A Critique of React Hooks Addendum(dillonshook.com) |
A Critique of React Hooks Addendum(dillonshook.com) |
I've been hearing a lot of "oh we don't use Redux, we use hooks" lately, as if this obviously makes sense.
Am I missing something? To me this seems like "oh we don't use Redux, we use arrays". I'm gonna need quite a few more details before I can make any sense of a statement like that.
Like... what? How... how does that explain what you're doing? One of these things is not like the other. "Oh we don't use doors on our buildings anymore, we've switched entirely over to trees". Huh? What the actual hell does that mean?
Context and hooks don't "replace Redux", but they do overlap with some of the scenarios and use cases that previously led people to choose Redux.
Please see my post "Redux - Not Dead Yet!" [0] for information on how Redux compares to tools like React context + hooks and GraphQL, as well as situations in which it makes sense to use Redux.
I'd also suggest reading my post "React, Redux, and Context Behavior" [1] and watching my Reactathon 2019 talk on "The State of Redux" [2] for additional information on these topics.
As you noted, "hooks" and "Redux" are not exclusive. We released our React-Redux hooks API [3] last year, and it's been pretty enthusiastically adopted. We're now updating our docs to show using the hooks API as the default instead of `connect`.
[0] https://blog.isquaredsoftware.com/2018/03/redux-not-dead-yet...
[1] https://blog.isquaredsoftware.com/2020/01/blogged-answers-re...
[2] https://blog.isquaredsoftware.com/2019/03/presentation-state...
Render props and HoCs solve similar problems for composition/reuse of functionality (these are all mixins at heart), but the hoistability of hooks is really the distinguishing mark in my experience.
You can DIY a Redux imitation with hooks pretty easily but making it as performant as Redux is harder.
If something else comes along and fits one of those niches, it's no wonder people will get interested in it. It was the same with Apollo. A lot of projects replaced Redux with it.
And to answer your question: some people are moving to hooks because of useReducer. Others because of useContext. Others because they can create custom Hooks. Some because of third-party hooks. Others for a mix of those.
Most of the people saying that are using that are suggesting it lowers the code complexity as in the code is easier to understand or follow.
They probably will also split up the application state in multiple React context, one for auth, one for settings, things that aren't depending on one another.
Especially, when you are application doesn't have to manage that much state yet. I think it's a reasonable approach to get started with it. You can always switch to something like Mobx state trees or Redux at later time.
Can't blame them missing the forest for the trees when you spend all your time writing the reducers and connectors vs the actions themselves.
[0] https://redux-toolkit.js.org
[1] https://react-redux.js.org/api/hooks
[2] https://redux.js.org/style-guide/style-guide#use-redux-toolk...
Until hooks I used redux in every app because it was the default way to manage state. Now I use hooks, I have more tools to help me manage state (and also load things via useEffect), I find I simply don't need redux anymore. The only compelling reason for me to pull in redux now would be if I wanted a centralised cache, but the kind of line of business apps I mostly work on lately just don't need to cache things like that, so each route/page just reloads the data from the server.
If Redux is a a vanilla-ish JS store and a Reactified access pattern, keeping the store but replacing the access pattern with React Contexts.
I am not a React expert.
We did this since the thing we are currently building is essentially just a set of forms with a lot of client-side and server-side validations.
Of course, if we were building a large SPA we would probably reconcider at this point. It feels like we're already at the edge of what useReducer was designed to do and I do not think what we are doing now would scale cleanly to a larger project or a larger team.
I would also struggle with similar quiz based on the callbacks for class components. And those I actually had to deal with on a frustratingly regular basis! At least with hooks I can remain blissfully ignorant of what happens under the covers of useEffect().
Maybe the answers don't matter and this is a pointless exercise.
- The "effect behavior runs bottom to top" has always been true about class lifecycle methods like `componentDidMount` / `componentDidUpdate`. So, nothing new there.
- Somewhat similarly, the aspect of new prop references causing some logic to run every time is not completely new, either - it's similar to how attempts to optimize rendering via use of `PureComponent`, `React.memo()`, and `shouldComponentUpdate` can "break" when the parent component passes down new callback or data object references every time.
- The complaint that "there's more stuff to learn" seems superfluous. If there was never anything new to learn, that would mean that the API was completely stagnant and that nothing new could ever be introduced. Yes, the ecosystem is in a somewhat uncomfortable transition state atm given that there's two different APIs that offer equivalent functionality, but "learning more stuff raises the barrier to entry" is not a particularly meaningful argument against hooks.
Quizzing the community on its supposed expertise, is such an effective way to separate rhetoric from reality.
Questions 3 and 4 about anonymous objects and useRef are definitely the kind of knowledge that someone who aims to understand React and Hooks should focus on, though.
- https://github.com/reduxjs/react-redux/issues/1177
- https://blog.isquaredsoftware.com/2018/11/react-redux-histor...
I find using apollo's graphql client library solves this reasonably well too, though the syntax is a bit clunky and knowing when you need to explicitly define a cache function or not is tricky.
There are some places where functionality is dependent on hooks.
React fast refresh won't work with class components. (useState is the hook alternative to class style state management and fast refresh is fancy hot reloading but with persisted state and only reloading modified modules/components).
There are few escape hatches only built as hooks mostly for improving performance issues which weren't previously available. But most of the hooks are basically reimplementation of features from class style components.
There are differences in how hooks work though. Hooks are executed as they are laid out.
Previous life cycle methods were dumped into a single useEffect hook.
It's easy to change hooks and introduce separation in how you build your logic is what I assume they might be referring to.
Instead of
<Consumer>
{({text}) => {
return <div> {text} </div>
</Consumer>
You can do
const [data] = useConsumer()
return <div> {data.text} </div>
It gets messy with a real complex application.
typing on mobile is sad.
If you have a team you need discipline, code reviews, and leadership. No state solution is going to solve this for you.
Maybe extra tooling could be built to avoid this, if we weren't already drowning in linter plugins...
I also disagree about the big re-write. Converting a hook's data/state to come from a prop instead is a very simple change.
I believe this model has similarities to both Apollo and Angular services, though I don't have direct experience with either.
EDIT: quick example here https://codesandbox.io/s/unruffled-easley-ry6x2?file=/src/Ap...
This is a fairly innocuous example since the bug is immediately apparent from the button not working. Now imagine the failure mode is more subtle, and these components are about two dozen layers apart down the tree.
And I'd like to be very clear that I strongly advise against cutting through layers with context because I wholeheartedly agree with your assessment there. You can plumb down those handles explicitly through props and enforce they're provided in a type system.
At the same time, unless I'm really misunderstanding the example you shared, I can't see the problem or mental overhead you're mentioning where we need to be vigilant about having the same hook used in multiple places or understanding the scope of the hook's "local" state and callbacks. That's the point of hooks as a unit of encapsulation -- just like with a class, each use of a hook is a different instance, and the scope is that of the instance (and hook instances are scoped/bound to the lifecycle of the containing component instance). The code in the problem you showed is equivalent to calling setState on the one component instance and expecting that to show up on another instance which happens to be of the same component class. If we understand how React component instances work, that's clearly not the case (state isn't broadcast across instances), and the same goes for hooks.
Looking at what I mean by the improved portabiliy/hoistability of hooks I mentioned in previous comments, let's say we have three components: App, Foo, and Bar. App renders Foo and Bar as children.
We have a business requirement that Foo has some behavior which contains multiple pieces of state and bindings to multiple React lifecycle events (e.g. mount). What we don't know is whether we'll ever need to share that behavior with Bar.
React class API: We need to write bindings for this behavior against class state and lifecycle methods, intermingled with other code. This intermingling means you know there's a good deal of refactoring to do to move the behavior upward to App if we ever need to share the behavior with Bar. As a component grows, more and more logic intermingles on those lifecycle methods and makes refactoring more challenging.
class Foo extends React.Component {
state: {
behaviorState: {...},
unrelatedState: {...},
};
componentDidMount() {
initBehavior(this.props.input);
initUnrelated();
}
...
}
const Foo = ({ input }) => {
const behaviorState = useBehavior(input);
const unrelatedState = useUnrelated();
return ...;
};
If this example sounds trivial, I've packaged up 500+ lines of functionality in a single self-contained hook before, and that's all exposed as a single function that consumers can treat as a full encapsulation of all of that functionality, while not worrying if they need to hoist that function call up and pass the output down at some point in the future.
I'm not talking about calling the same hook in Foo and Bar (these are different instances), nor sharing local state sideways across different invocations of hooks, but rather having full confidence it won't be hard to re-anchor that hook upward in the component tree if need be.
> One of the problems Redux is used to solve (as a global store) is peace of mind that you won't need to refactor large swathes of component trees to reparent state and callbacks that need to be shared or persisted across different subtrees as new business requirements arise
> Hooks (especially custom hooks, which are just a composition of other hooks packaged together as a single function) make the reparenting/hoisting/anchoring of state and callbacks trivial compared to other mechanisms, providing similar peace of mind that you're not boxing yourself into an inextensible component tree. (This is regardless of context; passing down props isn't a large pain point, and is often misguided to try to solve because it leads to importable components and hidden contracts.)
My earlier example was to show that re-parenting/hoisting when you replace a global store like Redux, with custom hooks using local state, is not straightforward, and unsafe except for very localized components where you shouldn't be using Redux anyway.
So you'll eventually end up doing prop drilling, or resorting to Context, or back to Redux; in the end hooks did not solve those issues as you proposed (other than the increased portability compared to classes, which you already have with redux or context).