Why Redux is strongly recommending to use hooks API?

[neerajkh96]

In the latest docs of React-redux, they are strongly recommending to use React-redux hooks API, while the connect() method is already much stable and mature than this.
the doc link is https://redux.js.org/style-guide/style-guide#use-the-react-redux-hooks-api.
I understand that hooks have less indirection, less code to write, and are simpler to use with TypeScript than connect is, but it comes with tradeoff than connect does in performance.

I just want to understand if hooks API still has tradeoffs in performance than why at first place it is strongly recommended.

[markerikson]

Multiple reasons:

• Hooks are where the React team is headed long-term
• The React community has eagerly adopted hooks in general
• The React-Redux hooks API is much simpler to understand and use for most people than connect is
• As you noted, the hooks are much easier to use with TS
• The hooks API is also smaller in bundle size

I disagree that there is a tradeoff in performance. The only difference perf-wise is that the hooks API cannot stop the current component from rendering when the parent component renders and passes down the same props, because hooks run inside of a component while connect wraps a component. But, it's trivial to wrap components in React.memo() yourself as needed, and in fact that's actually what connect does internally as of v7 anyway.

Similarly, I also disagree that connect is "more stable and mature". Sure, connect has been around much longer than the hooks API, but the hooks API has been very stable since we released it in June 2019. In fact, because it's much simpler internally, we've had much less need to do maintenance work on the hooks API, whereas connect's implementation is a hodgepodge of edge cases and complexity that's accumulated over the years.

At this point, both implementations are highly stable and mature.

[neerajkh96]

Related to the stability, the useSelector is marked as strongly recommended from the release version 7.1.0, and since then there were issues available in the useSelector. In release version 7.2.2 the component was rendering twice if we go with this while in Connect it was all working fine. And also, the releases from 7.2.1 onwards shows that in every release there is something has been fixed in useSelector() Api.
The change log is available at https://github.com/reduxjs/react-redux/releases.
So, IMO this raises a question on the stability part for useSelector() while the Connect has been doing good from a long time.

Additionally, there are some couple of points too:

1. the useSelector() comes with its usage warning while there is no such thing for Connect. https://react-redux.js.org/api/hooks#usage-warnings
2. the redux style guild recommends to use useSelector, but at the same time contradicts the statement with some trade off than Connect method, https://redux.js.org/style-guide/style-guide#use-the-react-redux-hooks-api
3. the default comparison in useSelector is a strict reference comparison, and we have to include 'shallowEqual' method to have the shallow comparison, while the connect does this automatically for us. https://react-redux.js.org/api/hooks#equality-comparisons-and-updates
4. the doc suggests us to use reselect library to create a memorised selector if the useSelector returns multiple values in one object,. While at other hand, there is no such dependency on any third party library for 'connect' method.
5. If parent component re-renders then the child will also re-render if React.memo is not used, the Connect does this things for us too.
6. IMO, the connect provides us the ability to separate the redux-logic separated and the component is more simplified for the unit testing. the separation of logic is quite not possible in useSelector, (This point is arguable, I have just added my opinion).

Here, the whole concern is that the library is recommending for a feature which is not adding any much helpful advantages over the existing solution. Both solutions can be implemented easily in the projects, but it should be left with people to select between one basis on their requirement and understanding. The recommendations create conflicts if the other perfect solution already available for it that too from a long time.

[markerikson]

I'm afraid I'd have to disagree with almost all the points you're making here.

First, "stable" does not mean "no changes whatsoever". It does mean that the functionality works as expected, that there are no major bugs, and that there are no frequent or breaking API changes.

Let's review the actual list of releases since we put out hooks in 7.1.0:

• v7.1.1 (2019-07-25): allowed custom contexts for hooks
• v7.1.2 (2019-11-05): bugfix for both connect and useSelector for React Native usage; bugfix for connect accepting non-store values
• v7.1.3 (2019-11-05): stupid leftover console.log() :)
• v7.2.0 (2020-02-17): bugfix for connect to fix memory leaks and improve unsubscribe behavior
• v7.2.1 (2020-07-25): selector debug values; minor useSelector bug fixes
• v7.2.2 (2020-10-26): React 17 peerDep bump
• v7.2.3 (2021-03-22): useSelector perf optimization; @types/react-redux included
• v7.2.4 (2021-04-24): removed redux runtime dep; useSelector selector behavior fix

That's 8 releases in a 2+ year span. Two of those don't even count meaningfully (7.1.3 and 7.2.2). Of the other 6, 2 had bug fixes for connect, 4 had fixes for useSelector, and one was a new feature for useSelector. So, complaining that "all the recent releases had fixes for useSelector" is an unfair characterization.

No code is perfect. In fact, I actually just recently figured out an improvement for the Subscription class we've been using in connect since late 2016 - by swapping it from a class to a closure, I was able to drop a few hundred bytes. Code evolves over time. Just look at the React releases list at https://github.com/facebook/react/releases . Hooks came out in 16.8, and yet there's been plenty of changes and fixes with the implementation. Would you argue they "weren't stable"? No. Hooks were stable on release, and while there's been fixes to tweaks and edge cases, the APIs worked as expected upon release in 16.8, and we've been able to use them as intended since then. Same for useSelector.

Also, we didn't add the "use hooks as the default" notice in the API reference page until February of this year, in #1688. That's almost two years after the first release of the hooks API. We had plenty of time to evaluate the stability during that time and conclude that they were the right choice long-term.

As for your other concerns:

• The warnings about useSelector are there as an FYI to the community, for completeness, about things that could theoretically happen. In practice, we've had far more people complain about the fact that that those warnings exist than have ever complained about those issues actually happening in real life.
• There's no contradiction in the style guide. All code has tradeoffs, and nothing's perfect. When we compare the tradeoffs between connect and useSelector, the tradeoffs are in favor of useSelector. It's simpler to use overall, easier to use with TS, has a smaller bundle size, and is easier to learn. That's why we recommend it as the default.
• You're acting as though a shallow comparison is necessary or required. That's not the case. Reference comparisons work well as a default, and we give you the option to override that as necessary. In that sense, useSelector is more flexible than connect.
• Neither connect nor useSelector has any actual dependency on Reselect. However, we've always encouraged writing memoized selectors with Reselect for years, per the old 'Computing Derived Data" docs page and the new "Deriving Data with Selectors" docs page, and people have been using Reselect with connect ever since React-Redux came out. Absolutely nothing has changed here.
• And per the last two points, yes, the differences in wrapping a component vs using hooks is part of the tradeoffs we've described. I covered these in detail in my post Thoughts on React Hooks, Redux, and Separation of Concerns and my talk ReactBoston 2019: Hooks, HOCs, and Tradeoffs. You're basically complaining that "useSelector is not the same as connect". Well, yes, that's sort of the point - they're not exactly the same thing. You can't go around complaining that an apple is not an orange, and use that as a negative statement about an apple.

connect is still there if you want to use it, and it's not going away. But useSelector works, it works well, and there's good reasons for us to recommend using it as the default.

[SRachamim]

I don't see any reason to use useSelector instead of connect.

While the concept of hooks is invented, the concept of a higher order function is discovered. And this is why connect will always work and work well, but useSelector won't always work as expected. Mainly:

• Hooks are not type-safe. It will throw on run time if not placed correctly. 🤦
• You can't call hooks conditionally. Do your null check repeatedly on all of your hooks, recursively! 😈

While connect is just a function without anything special. 💪 No need to warn your consumer of various WTFs. (except of the fact that it will throw on runtime on environments that lack a provider, but this is the same limitation as in hooks, so this is entirely different discussion).

But the React team decided that this is the way to go, so let's go after them.

I mean, it's ok to have useSelector, but recommending it it's something else entirely.

[prechy123]

Honestly, in 2023 I'm not sure I'll choose React and Redux for web application development.

Anyway, If I must use React and Redux, I still prefer the simplicity and safety of a high-order function (a universal programming concept) over hooks (a React-specific trick).

1. Simplicity? I am not sure about that, I believe using hooks is as simple as it can get
2. So what will you use if not react and redux?

[SRachamim]

1. Hooks may have more ergonomic API. It may be easier to type. But IMHO it's not a simple concept to learn, teach, reason about, test and maintain. And more importantly - it's not a transferable knowledge. It's a React concept which I'll forget to master the moment React will go out of fashion. Compare it to a simple function which is the simplest form of computation we had, have and will have. If a function is too simple for you to implement reactivity, then you have many other universal concepts such as Observable (or signals, their new popular name).

2. Depend upon the use case of course. I don't have strong opinion here, but I assume most web applications today may use a simple MPA architecture with Lit and htmx. For more complex use cases I don't see why React is better than Solid, Vue, Preact or Svelte.

[markerikson]

@SRachamim : function components, props, and state are also all "React concepts". If you're writing React, you do need to know and use React concepts, in the same way that writing Angular would require that you know how to use decorators and specify templates in order to write components.

If you don't want to use React, sure, that's totally up to you. But hooks are a core part of React's APIs. If you're using React, you need to know how to use them, period.

[SRachamim]

Function components, props and state are universal concepts. They are not a React concept. Every programming language since 1959 had functions, arguments and "state". And every programming language today and in the near future has them. React just composes those concepts to achieve a solution to some problem. Everyone know how to use those concepts even without learning React.

Compare it to "hooks" which is something new that exists only in React, with many limitations and edge-cases and a brand new way of thinking. And it's not even a successful concept. As you can see, most modern UI libraries prefer to leverage the universal Observables concept (by way of using "signals").

A good library is one that composes simple universal concepts into a nice API. Not necessarily one that invent a new style of thinking (let's prevent developers from using if to conditionally executing (hooks) functions).

[markerikson]

This really isn't the right place to argue about whether hooks themselves are a good idea or not.

They're part of React, and the job of React-Redux is to expose Redux's functionality in a way that's integrated with React.

(to be clear, I don't like behaviors like the inability to call them conditionally. But that's not the question at hand.)