It wasn’t clear to me the why, as in what are the benefits of event sourcing, as oposed to command…
Hà Nguyễn

If you have insights on how your app is used, then you might realise that for example you can remove “this button” since nobody is using it (in case there are multiple ways to achieve the same goal as I presented in my post).

Another benefit of events describing facts is — simpler container components.
Here is an example why that would be beneficial for an infinite scroll view (original post):

For example imagine an infinite scroll view. CONTAINER_SCROLLED can lead to NEXT_PAGE_LOADED, but is it really the responsibility of the scrollable container to decide whether or not we should load another page? Then he has to be aware of more complicated stuff like whether or not the last page was loaded successfully or if there is already a page that tries to load, or if there is no more items left to load? I don't think so: for maximum reusability the scrollable container should just describe that it has been scrolled. The loading of a page is a "business effect" of that scroll.

Also, I find beneficial the idea of a process manger which represents a single place to define your action flow (so you don’t have to inspect container components to find out what will happen on user interaction)

But, There are always trade-offs and this might not be beneficial for every app, especially for “small ones”.

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.