jingc's comments

The stores contain the data, but they also include the logic for updating that data. For example, a store of all the comments would also subscribe to events for new comments and add them into the comment thread at the correct location. We've found it more maintainable to keep the application logic for a set of data and the data itself in one place rather than having a model that external pieces can modify.

Agreed, we found that property really nice too - optimistic updating and rolling back on error were similarly easy

We do still use React state, especially for view state like whether a piece of text is expanded or whether the viewer has toggled the grid or list view on a table. But as you said, most of our data is pulled into a store layer that doesn't have React dependencies.

Yup, we've used it that way, and it's easy to implement due to the fact that all changes are expressed as a payload object, which allows you to serialize actions. Optimistic actions (showing the Like when the server hasn't confirmed yet) are built the same way - the stores just need to resolve between the optimistic/offline update and the eventual server response.

Thanks lhorie, it's great to hear that you've come to similar conclusions. I found that https://tech.dropbox.com/2014/04/building-carousel-part-i-ho... also described similar concepts, which is really encouraging.

To address your second comment: One distinction between the dispatcher and controllers in the MVC framework is that the dispatcher generally doesn't contain any business logic. It's essentially a hub for passing messages through: all sources of changes get funneled through the dispatcher, and the stores listen for those events, but the dispatcher doesn't actually modify or initiate the events. In my talk, I described it as the traffic controller of the system, which might be a more appropriate description.

As things get more complicated, the dispatcher may do more things at the framework level (Bill refers to the dispatcher handling dependencies between stores), but it stays separate from the application logic. In other words, we use the same dispatcher for multiple apps, so it plays a different role from the controller.

Hope that clarifies a bit, I'll see if we can make this distinction clearer in the documentation :)