React Redux earns its place after the store decision
React Redux 9.3.0 connects React components to a Redux store. Provider puts the store into React context, useSelector reads selected state, and useDispatch sends actions. The library does not create the store or decide how state should be modeled. Its README sends new projects to Redux Toolkit templates for Vite and Next.js, while existing apps must install Redux and configure a store separately.
That boundary should decide adoption. React Redux is a sensible dependency when an app already benefits from Redux's explicit events and shared state. It is weak justification for adding Redux to a smaller app. The checkout we measured contains 208 files and about 12,626 source lines, yet its public API still asks developers to understand the store, selectors, action dispatch, and component subscriptions. A short install cannot answer whether that model suits your application.
Version 9.3.0 prefers hooks while keeping connect alive
The May 15, 2026 release marked connect as deprecated. The release notes also say its behavior is unchanged and the maintainers do not intend to remove it. Existing class components therefore keep a supported bridge, and legacy_connect removes the editor deprecation mark when a team needs it. New code should use useSelector and useDispatch, which the docs describe as the default approach.
TypeScript support is unusually practical. Since v8 the package has shipped its own types, and v9.1.0 added withTypes helpers for selector, dispatch, and store hooks. A project can infer RootState and AppDispatch from its store, then export app-specific hooks from a separate file. That avoids repeating types inside components and prevents a plain Dispatch type from forgetting thunk middleware. The docs also explain ConnectedProps for teams that still have typed connect wrappers.
What happened when we ran it
Our sandbox installed the commit 0b4e333 checkout in 7 seconds. Pnpm added 1 package and the installed tree occupied 189 MB. The build completed in 4 seconds, then Vitest passed 187 of 187 tests in 11 seconds. Nothing in the supplied run failed, and the repository was only 2 MB before installation.
The checkout had 4 CI workflow files, a tests directory, and monorepo workspaces. It had no Dockerfile, which is a neutral result for a package consumed inside another application. The useful outcome is the clean build and complete test pass on Node 22 in an unprivileged Debian container with 3 CPUs and 8 GB of RAM. Those results cover repository mechanics, not render speed inside a production interface.
useSelector makes reference discipline part of the job
The hooks documentation states that useSelector compares its previous and current result with strict reference equality. Return a fresh object for every call and the component rerenders after every dispatched action unless you use memoization, shallowEqual, or another equality function. Development checks can warn when a selector is unstable or returns the entire root state, but the default stability check runs once rather than policing every production update.
Open issue 2255 gives the caveat a concrete shape. Its React Redux 9.2.0 example combines a selector that creates a new object, a callback depending on that result, and an effect that dispatches another action. The reporter describes an infinite rerender loop. That report does not make every inline selector unsafe. It does mean a migration from v7 should include selector-reference tests, especially where effects dispatch and older code builds objects in mapStateToProps.
The official docs also retain warnings about stale props and "zombie children" when hooks use props inside selectors. Connect creates nested subscriptions; hooks cannot reproduce that hierarchy. The maintainers call these cases rare and suggest defensive selectors or a connected ancestor when they appear. This is useful candor, and it is a reason to read the hooks page before replacing every connect call mechanically.
React 18 SSR has a documented hydration path
React Redux 9 requires React 18 or 19 and declares Redux 5 as its peer version. For server-rendered React 18 apps, Provider accepts serverState. The docs tell you to create the client store with the serialized initial state and pass that same snapshot to Provider, so the first hydration render matches the server HTML. There are no service accounts or API tokens to provision.
The runtime setup is small, though it is still real configuration. Provider must wrap every component using the store. Custom contexts must match between Provider and consumers. TypeScript projects should define typed hooks outside the store module to avoid circular imports. A team that copies only the npm install line will miss the decisions that affect rerenders, hydration, and test design.
Current maintenance does not settle the concurrency question
GitHub showed a September 19, 2026 push, 23,430 stars, 27 open issues, and 11 open pull requests. The same day's commit fixed documentation search. Together with the May v9.3.0 release and 4 visible CI workflows, that is clear evidence of active maintenance. Several older issues concern specialized rendering behavior, so their substance matters more than the raw queue size.
Issue 2086 remains open after a July 30, 2026 update. Its reproduction on React 18.2.0 and React Redux 8.1.3 reports that Redux updates wrapped in startTransition still render synchronously. Because the report used an older library version, verify the behavior on your own v9.3.0 workload before treating it as a current limit. Interfaces depending on interruptible rendering should make that test part of adoption, not assume the wrapper changes Redux subscription semantics.
Our 187-test pass makes React Redux low risk to try. The harder choice sits one layer below it: does the app benefit from Redux enough to own selectors, actions, and store conventions? If the answer is already yes, this is the binding to use. If the team cannot explain why the Redux store exists, React Redux cannot supply the missing reason.