The problem is when different views require the same concept of some state but they don't really want it global to the application to bleed into other views. A

The problem is when different views require the same concept of some state but they don't really want it global to the application to bleed into other views. A redux-like pattern makes it very simple to put that state into a store, but then you're stuck reseting it every time you switch views, which can make it very easy to introduce timing bugs and just increases the surface area where bugs can introduce since more code gets written for logic that ultimately is the wrong abstraction for these situations. I suspected this would be the case when first reading about redux, and dealing with it at practice in work, the consequences can be quite bad. Not to say that some concept of global application state is bad - one always has it. It is incorrectly making it global when you really want an instance of it for a particular view. Redux itself isn't bad as it helps manage an important situation, but it is too much of a facilitator of this antipattern when it comes to state that absolutely should not bleed across views.