Legacy Redux
Discouraged
This page covers legacy Redux patterns — hand-written action constants, manual reducers, connect() HOCs, and vanilla middleware chains. These patterns are discouraged for new projects and new feature work, though existing legacy Redux codebases may still need maintenance or incremental migration.
For new work that genuinely needs Redux-level state management, use Redux Toolkit. For most projects, Zustand is the recommended default.
What is it
Legacy Redux refers to pre-RTK patterns for using Redux: manually defined action types, switch-case reducers, mapStateToProps / mapDispatchToProps with the connect() higher-order component, and hand-configured store enhancers. These were standard practice from 2015–2019 but have been superseded by Redux Toolkit.
Why it's discouraged
- Massive boilerplate — action constants, action creators, reducer switch statements, and
connect()wiring multiply the code needed for even simple state changes. - Error-prone — typos in string action types cause silent failures; mutable state bugs are easy to introduce without Immer.
- Poor TypeScript experience — typing
connect()and thunks manually is notoriously difficult compared to RTK's inferred types. - No longer maintained as a pattern — the Redux team explicitly recommends RTK and considers legacy patterns obsolete.
- Harder to onboard — new developers must learn outdated idioms that don't transfer to modern Redux or other state libraries.
When it makes sense
- Existing legacy codebases where rewriting is not feasible — if the app already uses legacy Redux and a migration to RTK or Zustand is not currently justified, continue maintaining it. Prioritize incrementally adopting RTK slices within the existing store when possible.
Alternatives
- Zustand — recommended default for most client state needs.
- Redux Toolkit — modern Redux for complex cases that genuinely require a centralized store with middleware, DevTools, and RTK Query.