Flux architecture (Vuex implementation)

[0xinterface]

For a more clear separation of duty within the application structure, I propose that we should consider implementing the Flux architecture, a brief overview of flux is as follows:

Flux applications have three major parts: the dispatcher, the stores, and the viewmodels (vue components). These should not be confused with Model-View-Controller. Controllers do exist in a Flux application, but they are controller-views -- views often found at the top of the hierarchy that retrieve data from the stores and pass this data down to their children. Additionally, action creators — dispatcher helper methods — are often used to support a semantic dispatcher API. It can be useful to think of them as a fourth part of the Flux update cycle.

Flux eschews MVC in favor of a unidirectional data flow. When a user interacts with a React view, the view propagates an action through a central dispatcher, to the various stores that hold the application's data and business logic, which updates all of the views that are affected. This allows the store to send updates without specifying how to transition views between states.

[clementf2b]

The Flux architecture is difficult to implement but should be quite useful for our project

[BrianSo]

@narwhlae When will you have your update on the vuex implementation?