Architecture in the Client ?

             Flux

The hardest part about software engineering is not writing code. It’s the ability to look at each problem with a fresh perspective, independent of solutions you have implemented in the past.

Flux is the application architecture that Facebook uses for building client-side web applications. It complements React’s composable view components by utilizing a unidirectional data flow. It’s more of a pattern rather than a formal framework, and you can start using Flux immediately without a lot of new code.

The core of the Flux pattern

Flux has four roles: actions, stores, the dispatcher and views. Their responsibilities can be defined as following:

• Actions are simple objects with a type property and some data. For example, an action could be {“type”: “IncreaseCount”, “local_data”: {“delta”: 1}}
• Stores contain the application’s state and logic. The best abstraction is to think of stores as managing a particular domain of the application. They aren’t the same as models in MVC since models usually try to model single objects, while stores in Flux can store anything
• The Dispatcher acts as a central hub. The dispatcher processes actions (for example, user interactions) and invokes callbacks that the stores have registered with it. The dispatcher isn’t the same as controllers in the MVC pattern — usually the dispatcher does not have much logic inside it and you can reuse the same dispatcher across projects
• Views are controller-views, also very common in most GUI MVC patterns. They listen for changes from the stores and re-render themselves appropriately. Views can also add new actions to the dispatcher, for example, on user interactions. The views are usually coded in React, but it’s not necessary to use React with Flux

The general flow of a Flux application can be defined as following:

The most important thing to note is that every change goes via an action through the dispatcher, illustrated like this:

So how is Flux different from MVC?

• The Flow of the app is essential to Flux and there are very strict rules that are enforced by the Dispatcher. In MVC the flow isn’t enforced and most MVC patterns implement it differently
• Unidirectional flow: Every change goes through the dispatcher. A store can’t change other stores directly. Same applies for views and other actions. Changes must go through the dispatcher via actions. In MVC it’s very common to have bidirectional flow
• Stores don’t need to model anything and can store any application related state. In MVC models try to model something, usually single objects

                                                                            Complex MVC Data Flow

Complex Flux Data Flow

Flux has just as many moving parts as MVC. That is why this diagram looks just as complex as the MVC diagram — but with one key difference: The arrows point in one direction, forming a consistent cycle through the system.

At Coupley we are using Flux and React for this project and the codebase so far looks very clean and is a pleasure to work with.

In general, I am more impressed with Flux than with React. The reason is that Flux is very simple to understand and there is almost no code for it—it’s just a way to better structure your app. React meanwhile has a huge codebase and a huge runtime complexity that I am not a huge fan of.