React context vs Redux in 2020
The React docs give some example use cases for context:
Context is designed to share data that can be considered “global” for a tree of React components, such as the current authenticated user, theme, or preferred language.
The common property of these use cases is that data like the current theme doesn't change often and needs to be shared deep down the component tree, which would be cumbersome with "prop drilling". Something else that needs to be shared everywhere is the application state when using a "single source of truth" pattern, so it would follow that the context API would help with that as well, but there's a catch: components that use context will rerender every time that the provided value changes, so sharing the whole application state through context would cause excessive render lifecycles.
useReducer() superficially seems like it could fill that role. Enter Redux Toolkit.
Redux Toolkit is a game-changer
Even the Redux FAQ comes with a strong caveat about the boilerplate (although placed in scare quotes) and developer overhead of using Redux, and related libraries like reselect and Immutable.js up the ante even more. At the same time, even weighed against the complexity, the benefits of Redux and the Flux pattern have been enough that Redux has significant community traction and an ecosystem of tools, including ones as nice as the Redux DevTools. Redux isn't something that can be easily written off as a bandwagon.
There have been a string of alternative state management libraries to simplify the boilerplate while using the same pattern as Redux, and Immer in particular has been a boon for this, but they largely haven't managed to reach maturity or to integrate with the existing tooling. Redux Toolkit changes this in that it's still Redux, has official approbation, the Redux DevTools and various Redux middleware still work, and it solves the boilerplate of defining and using actions, reducers, stores, etc., and of immutable updates (courtesy of Immer).
Redux Toolkit changes the calculation about when Redux should be used, making it sensible to just use Redux Toolkit by default in "greenfield" projects, even in simpler ones. Redux Toolkit doesn't offer anything special for async modeling like sagas, but
redux-thunk is fine.
Not everything can or should be put in a Redux store, and in particular it can't hold objects that can't be serialized, so that may be a use case for the context API if it helps avoid prop drilling (although it's a good idea to consider component composition first).