[always_good]

One benefit is that you have explicit events that create specific state changes. Your app is a succession of these events that certainly help when debugging and thinking about the potential states your app can be in.

Like other state management solutions, it also 'writes' all your shouldComponentUpdate methods for you.

[tehlike]

Sounds like event sourcing, for ui.

[acemarke]

There's been many comparisons made to event sourcing, but the actual semantics of the dispatched actions are up to you. You might dispatch `USER_LOGGED_IN`, or you could dispatch `SET_USER_LOGGED_IN_STATUS` (ie, "past-tense event that occurred" vs "present-tense imperative set some state"). Redux doesn't care how you name your actions. There's been lots of arguments over how action semantics should be viewed. I recapped some of the discussion in my post 'The Tao of Redux, Part 2 - Practice and Philosophy" ( http://blog.isquaredsoftware.com/2017/05/idiomatic-redux-tao... ).

[tehlike]

Sure, with event sourcing there is another level of difference between commands, query, events. But the similarity is there.