At the core of the Flux pattern is a unidirectional data flow. It uses some core concepts to achieve this flow. The main idea is when an event is created on a UI, through the interaction of a user, an action is created. This action consists of an intent and a payload. The intent is what your are trying to achieve. Think of the intent as a verb. Add an item, remove an item, and so on. The payload is the data change that needs to happen to achieve our intent. If we are trying to add an item, then the payload is the newly created item. The action is then propagated in the flow with the help of a dispatcher. The action and its data eventually end up in a store.

The concepts that make up the Flux pattern are:

• Action and action creators, where we set up an intention and a payload of data
• The dispatcher, our spider in the web that is able to send messages left...

Let's introduce all parties involved in our uniform data flow by starting from the very top and slowly work our way down, concept by concept. We will build an application consisting of two views. In the first view, the user will select an item from a list. This should result in an action being created. This action will then be dispatched, by the dispatcher. The action and its payload will end up in a store. The other view meanwhile listens to changes from the store. When an item is selected, the second view will be made aware and can therefore indicate in its UI that a specific item has been selected. On a high level, our application and its flow will look like the following:

Ok, so we have described the parts our application consists of:

• A view where a user is able to select an index
• A dispatcher that allows us to send a message
• A store that contains our selected index
• A second view where the selected index is read from the store

Let's build a real app from all of this. The following code is found in the code repository under Chapter2/demo.

First off we need our view in which we will perform the selection:

// demo/selectionView.js

import dispatcher from "./dispatcher";

console.log('selection view loaded');

class SelectionView {
  selectIndex(index) {
    console.log('selected index ', index);
    dispatcher.dispatch...

Let's do a reality check here. We haven't built the Flux flow as prettily as we could make it. The overall picture is correct but it'd be nice if we can clean it up a bit to make room for more actions so we get a real sense of how the application should grow from here.

The first order of business is to have a look at our first view and how it reacts to user interactions. It looks like this currently:

// first.view.js

import dispatcher from "./dispatcher";

class FirstView {
  selectIndex(index) {
    dispatcher.dispatch({
      type: "SELECT_INDEX",
      data: index
    });
  }
}

let view = new FirstView();

Adding a few more actions into the mix...

So far, we have only been dealing with static data in our Flux flow. The time has now come to add real data connections to the flow and thereby real data. It is time to start talking to APIs through AJAX and HTTP. Fetching data is quite easy nowadays, thanks to the fetch API and libraries such as RxJS. What you need to think about when incorporating it in the flow is:

• Where to place the HTTP call
• How to ensure that the store is updated and interested views are notified

We have a point at which we register the store to the dispatcher, with this piece of code:

// excerpt from store-actions-immutable.js

const createProduct = (product) => {
  if (!store["products"]) {
    store["products"] = [];
  }

  store.products = [...store.products, Object.assign(product)];
}

dispatcher.register(({ type, data }) => {
  switch (type) {
    case CREATE_PRODUCT...

So far, we have been describing a solution that consists of only a product's topic and communication has only taken place from one view to another. In a more realistic application, we would have a lot of topics such as user management, orders, and so on; exactly what they are called is dependent on the domain of your application. As for views, it is quite possible that you will have a ton of views listening to another view, as in this example:

This describes an application that contains four different view components around their own topic. The Customers view contains a list of customers and it allows us to alter which customer we currently want to focus on. The other three supporting views show Orders, Messages, and Friends and their content depends on which customer is currently highlighted. From a Flux standpoint, the Orders, Messages, and Friends...

We set out trying only to explain the Flux architecture pattern. It would have been very easy to start mentioning how it fits with React and how there are nice libraries and tools that support Flux and React. That would, however, have taken our focus away from explaining the pattern from a more framework-agnostic viewpoint. Therefore, the rest of this chapter set out to explain core concepts such as actions, action creator, dispatcher, store, and uniform data flow. Little by little, we improved the code to start using constants, action creators, and a nice supporting library such as EventEmitter. We explained how HTTP fits into this and, lastly, we discussed how we could build out our application. There is a lot more that can be said about Flux, but we chose to limit the scope to understanding the fundamentals so we can compare its approach as we dive into Redux and NgRx...