Hi, I'm a Redux maintainer. Redux and Context are different tools that solve different problems, with some overlap. Context is a Dependency Injection tool for a single value, used to avoid prop drilling. Redux is a tool for predictable global state management, with the state stored outside React. Note that Context itself isn't the "store", or "managing" anything - it's just a conduit for whatever state you are managing, or whatever other value you're passing through it (event emitter, etc). I wrote an extensive article specifically to answer this frequently asked question, including details about what the differences are between Context and Redux, and when to consider using either of them - I'd recommend reading through this: https://blog.isquaredsoftware.com/2021/01/context-redux-differences/ Redux can be used for many different kinds of tasks. That includes managing purely client-only state, but it can also be used to cache server state (either by writing the data fetching + caching code yourself, or using our RTK Query data fetching and caching layer). If the primary thing that you're doing in the app is caching server state, and you're already using React Query, then yeah, you almost definitely don't need Redux at that point - you've already chosen a different tool for that job. More on reddit.com

Hi, I'm a Redux maintainer. I'm also about to head to bed, so I'll keep this answer shorter than usual :) Redux, even at the time of its creation, was not "new" or utterly unique. In fact, it was inspired by numerous existing patterns and libraries : the Flux architecture, Elm, and many others. But, it's important to understand the time and context in which Redux was created: React had only come out 2 years earlier Backbone, AngularJS, and Ember were still prevalent React had its original context API, but that was badly broken for updating values The React ecosystem had just spent a year of "The Flux Wars" with dozens of Flux-inspired libraries competing React had enough Functional Programming principles in play that the community tried to make use of those The mental model and problem domain to be solved were "client side state management" + "side effects" Redux addressed a lot of problems at the time: It was simpler than Ember or AngularJS, and didn't have the "multiple events" problem of Backbone It made it easy to access global state anywhere in the component tree and update properly, which legacy context couldn't do right It was designed to work with React and based on functional programming principles It was a better Flux Architecture implementation than any of the other Flux libraries It let you plug in your choice of side effects middleware (thunks, sagas, observables, or many others) the Redux DevTools were a huge improvement over what any other state management tool had, and went along great with the React DevTools the concept of "time travel debugging" sounded great. So, Redux ended up killing off all the other Flux libraries, and folks soon began to assume that if you were using React you had to use Redux. (This led to Redux being shoved in many apps that never needed it in the first place). Then the ecosystem needs changed. The mindset changed from "client side state management" to "fetch and cache server state", which led to React Query, Apollo, SWR, and Urql. React's new Context API came out and worked properly for updating values. Folks who over-used Redux ran into the pain points, plus other libraries showed you could write state code in shorter ways. That led to the waves of backlash, "I hate Redux", "$LIBRARY kills Redux", and so on. That's why we created and shipped our official Redux Toolkit package, which eliminates the "boilerplate" complaints, builds in best practices, and has functions that simplify the most common Redux use cases (including RTK Query, a full data fetching and caching layer). Unfortunately, there's still a ton of very outdated tutorials showing legacy Redux patterns, even though we've taught RTK as the default standard way to use Redux for over 4 years (half as long as Redux has existed!). (Hint: if you see createStore or switch(action.type) or const ADD_TODO = "ADD_TODO", run away! That's horribly outdated, and you should be using RTK's configureStore and createSlice instead.) Today, Redux is still the most widely used client state management library in React apps, but the ecosystem has definitely changed. There's the pendulum swing back to server-side data handling (Next, RSCs, Remix, Redwood), client-side data fetching libs, client-side state libs like Zustand or Jotai or Mobx, React's own useReducer + Context, etc. We don't try to market or push people and say "you have to use Redux" or "you should use Redux". No tool is a silver bullet. There's always tradeoffs. Our goal is just to make Redux the best version of itself, so that if it solves the kinds of problems you have, and if you choose to use it, it will work great for you. Well, that was not short :) Lemme throw in a few reference links and call it a night: Redux docs: Why Redux Toolkit is How to Use Redux Today Redux Essentials tutorial: Redux Toolkit App Structure Using Redux: Migrating to Modern Redux My blog: Idiomatic Redux, Part 1: Implementation and Intent Redux and Context Differences and Use Cases More on reddit.com

You need it because sharing state between components can get really complicated really fast. If you rely strictly on Context, making sure you don't have a ton of excessive rerenders gets really complicated really fast. If your app is just a few components, Context is probably fine. But that's a very narrow window. Redux is kind of falling out of favor for new projects. I'm not saying it's not used anymore, but it's not the top dog and in every project like it used to be. Some alternatives are: Zustand Recoil Jotai More on reddit.com

If you're using Redux, then all global state that doesn't otherwise have a source of truth should live in your Redux store. But you should never store component state in your Redux store. What if you wanted to render multiple instances of a component? Then they'd all be bound to the same state instances. But also, you shouldn't try to track something like the router/URL state with Redux, as it already has a source of truth and trying to sync those state changes up in Redux and redeploy them to the real source of truth will only create risk and complexity. More relevant though is that Redux is major overkill for small apps (and honestly maybe even large ones too). You should consider Zustand over Redux for large apps, and Jotai over Redux for small apps. Even some of the original creators of Redux warn against introducing Redux to new applications. More on reddit.com