Flux vs MVC: Best Explanation
Flux architecture is the backbone of React.js. It's an alternative to MVC and other popular software design patterns. Facebook claims that it's superior in both scalability and readability. If you've used React or Angular 2, there's a good chance you've already designed an app using the Flux architecture.
As to whether or not the Flux pattern is superior to MVC remains debatable. Rather than explore which one is best, this article explains the key differences in Flux and MVC.
Unidirectional data flow
Angular is well known for its two-way data binding. When a user updates an input field on a view, the view directly updates the data model it represents. Likewise, when the model receives updates (via the controller) it propagates those changes to the presentation layer. This makes for bi-directional data flow, as the view and model are constantly kept in-sync.
Unlike MVC, the Flux pattern enforces a unidirectional data flow. A dispatcher receives user actions from the view and updates stores. These stores are similar to models in MVC, however they can contain multiple data objects. After receiving user actions from the dispatcher, each store updates the view(s) that are affected by the user action. It should be noted that application state is only handled in the stores. This maintains a strict separation between different parts of the app. This means that the view can't mutate the app's existing state directly. Rather, the view creates an actionable item that generates a new state. This new state replaces the current one only where necessary.
So What?
What makes unidirectional data flow so much better? While two-way data binding keeps an app's state closely bound to it's presentation layer, things can get out of hand fast when your app grows in complexity. One controller may have several models with several corresponding views. Advocates of Flux argue that this leaves apps prone to 'cascading events' and 'nested upates'. With bi-directional data flow, views can update models that unexpectedly trigger other models to update other view, etc. Things can get out of hand fast.
This makes a strong case for unidirectional data flow, as user actions only propagate changes from one direction. This is especially useful for larger apps with many models and views. Developers don't need to worry about how a new feature will affect other components. Instead they can focus on building independent features that respond to existing user actions / events.
