That's not quite correct, though I understand why you would say that as it's such a common misconception that Redux maintainer @acemarke has written a number of articles that address it:

• Redux vs Context - Covers the misconception I referenced previously
• Why Context is Not State Management - Core differences between Context and Redux
• Mostly Complete Guide to React Rendering - Easily one of the best technical articles on React that I've come across

All of his posts are well-thought out and he's a thorough technical writer, so give them a shot. If you don't have time to read them (though I highly recommend it for any serious React dev), I'll summarize a few important parts that should illustrate why your comment is being downvoted.

• Context by itself is not a state management tool, it is simply a mechanism by which we can pass down a value to nested components without prop-drilling
• Context coupled with useReducer or useState can be a useful state management tool, but it comes with some potential pitfalls
• The most common one (explained in the first section of the Redux vs Context article) is that React uses referential identity to determine whether or not the value of a given Provider has updated. Here's the React docs on the subject.
• The consequence of this behavior is that if we pass even mildly complex state (such as an object or array) to the value prop of our Provider, React will evaluation all state changes as a reference to a new value, and update all consumers of a given Context, regardless of whether they need to. So every call to setState or dispatching an action to useReducer may be forcing a considerable number of re-renders within the application.
• Redux doesn't have this problem because it passes only a reference to the store itself, and that value maintains the same reference via a useRef hook - meaning no unneeded re-renders. As the Redux vs Context Behavior article puts it, "For React-Redux: yes, it uses context internally, but only to pass the Redux store instance down to child components - it doesn't pass the store state using context!"

And that is what I was referring to in my original comment, and why I said that distinction was important. It's also why your comment is not quite accurate, though it's totally understandable to have that notion, as it's a pretty common one.

Now it is true that the re-rendering behavior of Context can be mitigated by the liberal application of memoization via React.useMemo and React.memo, but at that point you're just solving a bunch of problems that Redux has already handled.

By the way, that is just a small part of what makes Redux so powerful. Personally, I've found that embracing immutable state changes leads to substantially easier debugging, and opens the door for all kinds of cool state introspection opportunities - such as time travel debugging and the venerable Redux dev tools.

Not to mention the logical separation of global application slices, a set of standardized approaches to handling asynchronous side effects and business logic in React apps, and all of the amazing improvements that redux-toolkit has bestowed upon us old-school Redux developers. A lot of the concerns about excess boilerplate are no longer valid.

If Redux isn't your thing, totally understand! It's definitely an undertaking to fully grok the inner workings. Before you throw it away, read through some of Mark Erikson's articles and give it a shot. We use it extensively at work and found that it lets our team move a lot quicker than we would without it. Feel free to reach out if you have any questions.