I understand the feeling that it seems strange to manage all state, no matter how small, in a large global state. However, every now and then I'll work with a designer or UX person who will connect seemingly unrelated elements in a powerful way, and I'll realize how freeing the global state becomes. The potential to easily explore new relationships between UI elements is wonderful.

Edit: Also, I should mention that taking advantage of the great middleware options for isolating side effects makes redux a treat to work with. I am using redux-observables, but I have heard great things about redux-sagas as well.

I've definitely felt that when using Redux even in some very simple projects. Just last night, for instance, I felt like I was doing acrobatics just to make a simple state update because a particular branch of the state required knowledge of state that was handled by a different reducer in order to do the update. However, as I struggled with navigating that issue, it slowly became really clear to me that the patterns Redux was enforcing (and which I was trying aggressively to circumvent) were actually to my benefit, and instead of circumventing it I just thought a bit harder about how my architecture and how to properly achieve what I wanted within the Redux paradigm. There will always be cases where libraries like Redux break down and you will feel like you are trying to fit a round peg in a square hole. But, at the end of the day, it's all just functions and objects being passed around and you have to judge the value in the library in the kinds of conventions and patterns it encourages and discourages. For me -- especially since I am admittedly a mediocre programmer at best -- the structure it enforced on my code organization and logic has been a blessing.

Im not sure I agree (or maybe I dont understand what you're saying). For me, all state, no matter how trivial, should be on the store. For UI state that can seem excessive, but its possible to use middleware and decorators to simplify that. Local state in my experience means bugs.

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.

I still dont think I grasp what your describing. The store isnt global. And you usually have domains on the store to namespace particular bits of state. But if need be, any part of your app can access that state if it needs to without having to dig down into your UI hierarchy which will likely change over time.

without wanting to sound patronising, but I wonder wether you're structuring things incorrectly.