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.

React.Js?

        What exactly is React.js?

In the simple and popular term, React is the V (View) in  MVC (Model/View/Controller).

In more descriptive terms, React is a JavaScript library (from Facebook) that is used to render views (for example, HTML pages) dynamically based on some state, which is often in the form of data. React then updates the generated views whenever the original state changes. React is a small but powerful library, with the power being more in the concepts than in the implementation.

---

Some of the concepts under which React operates:

Reusable, composable, and stateful components:
 In React, we build HTML views using smaller components. We can reuse a single component in multiple places, with different state and properties, and every component can contain other components. All components in React have a state that may change over time, and React will take care of updating the components’ views when their state changes.

The nature of reactive updates:
React’s name is the simple explanation for this concept. When the state of a component changes, those changes need to be reflected somewhere, for example, if we’re writing HTML components for a browser, we need to regenerate the HTML for the browser’s DOM (Document Object Model). With React, we do not have to worry about how to reflect the state changes, React will simply react to the changes and update views as needed.

The virtual representation of views in memory: 
For the browser’s case, we write HTML using JavaScript in React relying on the power of JavaScript to generate HTML that depends on some data, rather than enhancing HTML to make it work with that data. Enhancing HTML is what other JavaScript frameworks usually do (for example, Angular.js extends HTML with features like loops, conditionals, and others).

---

If we are receiving just the data from the server (with AJAX), we need something more than HTML to work with it, so it’s either using an enhanced HTML, or just using the power of JavaScript itself to generate the HTML. Each of these approaches has advantages and disadvantages, and React embraces the latter one, with the argument that the advantages are stronger than the disadvantages, and I, of course, agree.

Using JavaScript to render HTML allows React to have a virtual representation of HTML in memory (which is aptly named, the Virtual DOM), and React uses that to rerender the views virtually first. Every time a state changes, and we have a new HTML tree that needs to be written back to the browser’s DOM, instead of writing the whole tree, React will only write the difference between the new tree and the previous tree (since React has both trees in memory). This process is known as Tree Reconciliation, and I think, it is the best thing that happened to Web Development since AJAX!