[zzzaim]

From what I understand from your description, it seems that data access, server requests, etc. fall under the responsibility of Actions? Why not offload it to the Store?

e.g: ArticleActions.favorite fires off an ARTICLE_UPDATE action, the ArticleStore receives this and does the appropriate ArticleDAO asynchronous call and when done emits a change event to update any Views.

[wingspan]

We split out data mutations from data access (see https://news.ycombinator.com/item?id=7721542). One reason is that multiple stores may be interested in the COMPLETE calls. One example is when you have a store that tracks which items in a list are selected; if one of the item is deleted, this separate store, say ArticleSelectionStore, needs to handle the ARTICLE_DELETE_COMPLETED event to unselect that article.

[gbrits]

Would it be correct in saying that stores behave exactly (are) Eager Read Derivations as describe by Fowler? http://martinfowler.com/bliki/EagerReadDerivation.html.

I.e: they update themselves (eagerly, hence the name) based on changes from the data-access layer. They're able to choose themselves which transformations to do on the data in order for views/components to query them efficiently.