> Is it easy to replace Redux with another state-container or data-storage without updating entire app?

Yes. This is why I use Redux. All the other stuff like reproducibility, state persistence, and devtools are just icing on the cake.

Redux heavily encourages architectures where the vast majority of your app has no knowledge of how data is stored, fetched, or updated. I purposely architect everything so that Redux would be easy to remove -- not that I actually plan on doing it, but it's a good litmus test that my architecture is properly data-agnostic. The end outcome is that the majority of the code is "pure" -- that is reusable, composable, and predictable. It's also immediately obvious which code actually touches state (namely actions, reducers, and containers).

This reminds me of a recent article by the author of Redux, who wrote ["You might not need Redux"](https://medium.com/@dan_abramov/you-might-not-need-redux-be4...). It was refreshing how he emphasized that Redux is just an implementation of a design pattern (or a composition of a few), that it's not necessarily "the solution". If another state management library works better for some applications, then use that instead.

"Overhyped" implies that its popularity is not worth its value. It's clear that it has proven its value to a majority of developers working with React. Especially as applications grow larger, I've found that using Redux provides an intuitive pattern for sane state management.

It does have its pain points (verbosity, async actions) but there's a plethora of libraries one could choose from, depending on need and preference. Since the core functions are so simple, they can be adapted as needed - for example, in a recent project I wrote a wrapper (~20 lines) to extend actions and reducers with namespaces.

An additional advantage of Redux, I think, is that it's becoming widely adopted, so when I look at an open-source codebase built on React + Redux, it's so easy to understand the application architecture.