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

Hi, I'm the main Redux maintainer. Redux peaked in popularity in 2017, and the industry has shifted a lot since then. There's a lot of other tools that overlap with reasons people chose Redux (passing data down the component tree, caching server state, other state management approaches, etc). That said it's also true that many people still associate "Redux" with the original (and now legacy) hand-written style patterns that had so much boilerplate. I'll be honest and say that's both sad and frustrating :( We specifically designed and built Redux Toolkit to eliminate most of the "boilerplate" problems that people disliked (action constants, hand-written immutable updates, "having to touch multiple files", etc). We've taught RTK as the default and correct way to use Redux since 2019. RTK has been out for more than half of Redux's existence, and yet a lot of people have either never tried it or just assume that the old deprecated legacy approaches are still representative of Redux. On the flip side, we frequently have users tell us how much they enjoy using RTK to build apps. So, that tells me we accomplished what we were trying to do with RTK. Our goal has never been to try to "win market share" vs other libraries. Instead, we try to make sure that Redux Toolkit is a solid set of tools that solve the problems our users deal with, so that if someone chooses to use Redux for their app, RTK works great for what they need to do. I did a talk last year on "Why Use Redux Today?" , where I discussed the various reasons why Redux has been used over time, looked into which kinds of problems and tasks are still relevant today, and gave a number of reasons why it's still worth considering Redux for new apps in today's ecosystem. 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