Each time we speak about an application with a user interface, the MVC pattern comes out. But what is the MVC pattern? It is an architectural pattern that divides components into three parts: a Model, a View, and a Controller. You can see the classic diagram describing MVC in the following figure:

Most of the modern frameworks for progressive web applications use the MVC pattern. In fact, if you look at the Vue.js single file component shown in the following figure, you can clearly see the three parts of the MVC pattern:

The template and style parts represent the view section, the script part provides the controller, and the data section of the controller is the model.

But what happens when we need some data from the model of a component that's inside another component? Moreover, in general, how can we interconnect all the components of a page?

Clearly, providing direct access to the model of the components from other components is not a good idea. The following screenshot shows the dependencies in the case of exposing the models:

Vue.js provides a good way of communicating between parent and child components: You can use Props to pass values from a parent to a child component, and you can emit data from a child component to its parent. The following figure shows a visual representation of this concept:

However, when multiple components share a common state, this way of communicating is not enough. The following are the issues that would come up:

• Multiple views may share the same piece of state
• User actions from different views may need to change the same piece of state

Some frameworks provide a component called EventBus; in fact, the Vue instance itself is an EventBus. It has two methods: Vue.$emit(event, [eventData]) and Vue.$on(event, callback([eventData])). The following is an example of how to create a global event bus:

// EventBus.js
import Vue from 'vue';
export const EventBus = new Vue();

// HelloWorldEmitter.js
import { EventBus } from './EventBus.js';
EventBus.$emit('an-event', 'Hello world');

// HelloWorldReceiver.js
import { EventBus } from './EventBus.js';
EventBus.$on('an-event', eventData => {
 console.log(eventData);
});

Even with a global event bus, making components communicate is not easy. What if a component that registers to an event gets loaded after the event is fired? It will miss the event. This may happen if that component is inside a module that gets loaded later, which is likely to happen in a progressive web app where modules are lazily loaded.

For example, say that a user wants to add a product to the cart list. She taps on the Add to cart button, which is likely to be in the CartList component, and she expects the product she sees on the screen to be saved in the cart. How can the CartList component find out what the product is that should be added to its list?

Well, it seems that Facebook programmers faced similar problems, and to solve those problems, they designed what they called Flux: Application architecture for building user interfaces.

Inspired by Flux and Elm architecture, Evan You, the author of Vue.js, created Vuex. You may know Redux already. In that case, you will find that Vuex and Redux are similar, and that Evan You saved us time by implementing Vuex instead of forcing every programmer to integrate Redux inside a Vue.js application. In addition, Vuex is designed around Vue.js to provide the best integration between the two frameworks.

But what is Vuex? That is the topic of the next section.

Evan You defines Vuex as:

Without knowing Flux, this definition sounds a little bit obscure. Actually, Vuex is a Flux implementation that exploits the reactivity system of Vue using a single, centralized store, and ensures that the state can only be mutated in a predictable fashion.

Before focusing on Vuex itself, we are going to understand the fundamentals of Flux and how Vuex took inspiration from these concepts.

Flux is a pattern for managing data flow in your application, and it is the application architecture that Facebook uses for building its web applications. The following diagram shows the structure and data flow in Flux:

As shown in the preceding figure, Flux is divided into four parts, and data flows in only one direction. In the next sections, we will see how data flows through the following parts:

• Actions
• Dispatchers
• Stores
• Views

Although it is important to understand how Flux works, Vuex has its own implementation of Flux architecture that differs from Flux, and it will be explained in detail in the following chapters.

Actions define the internal API of your application. They represent what can be done, but not how it is done. The logic of state mutation is contained inside stores. An action is simply an object with a type and some data.

Actions should be meaningful to the reader and they should avoid implementation details. For example, remove-product-from-cart is better than splitting it into update-server-cart, refresh-cart-list, and update-money-total.

An action is dispatched to all the stores and it can cause more than one store to update. So dispatching an action will result in one or more stores executing the corresponding action handler.

For example, when a user taps on the Remove from cart button, a remove-product-from-cart action is dispatched:

{type: 'remove-product-from-cart', productID: '21'}

In Vuex, the action system is a bit different, and it splits Flux actions into two concepts:

• Actions
• Mutations

Actions represent a behavior of an application, something that the application must do. The result of an action consists typically of one or more mutations being committed. Committing a mutation means executing its associated handler. It is not possible to change the Vuex state directly inside an action; instead, actions commit mutations.

You have to deal with asynchronous code inside actions, since mutations must be synchronous.

Mutations, on the other hand, can and do modify the application state. They represent the application logic directly connected to the application state. Mutations should be simple, since complex behavior should be handled by actions.

Since there is only one store in Vuex, actions are dispatched using the store, and there is a direct connection between an action and its handler. In Flux, on the other hand, every store knows what to do when responding to the action.

You will read about the Vuex action/mutation system in the following chapters. Right now, you just need to understand the concepts behind actions, and that Vuex implements actions in a slightly different way than the one used by Flux.

There is only one dispatcher per application, and it receives actions and dispatches them to the stores. Every store receives every action. It is a simple mechanism to dispatch actions, and it can handle dependencies between stores by dispatching actions to the stores in a specific order.

For example:

1. A user taps on the Add to cart button
2. The view captures this event and dispatches an add-to-cart action
3. Every store receives this action

Since Vuex differs from Flux because the dispatcher is inside the store, what you should remember here is that every change in the application begins by dispatching an action.

Stores contain the application state and logic. Stores can be mutated only by actions and do not expose any setter method. There can be more than one store in Flux, each one representing a domain within the application. In Vuex, there is only one store, and its state is called a single state tree. Vuex is not the only framework that enforces the use of a single store: Redux explicitly states that there is one store per Redux application. You may think that a single store may break modularity. We will see later how modularity works on Vuex.

Before switching to Flux architecture, Facebook chat kept experiencing a bug where the number of unread messages was wrong. Instead of having two lists—one of read messages and another of unread ones—they used to derive the number of unread messages from other components events. It is indeed better to have an explicit state where all the information is stored. Think of the state as an application snapshot: You could save it before the application page gets closed and restore it when the application gets opened again so that the user will find the application in the same state it was left in.

There are three important concepts regarding stores:

• Stores can be mutated only by actions
• Once a store is mutated, it notifies it has changed to the views
• Stores represent explicit data, as opposed to deriving data from events

Here is an example of a store reacting to the add-to-cart action dispatched in the previous example:

1. The store receives the add-to-cart action
2. It decides it is relevant and executes the logic of the action by adding the current product to the cart product list
3. It updates its data and then notifies the views that it has changed

Views, or view controllers, display data from the stores. Here is where a framework like Vue.js plugs in.

In the Facebook video introducing Flux, software engineer Jing Chen talks about some of the problems they faced while developing Facebook Chat, and what lessons they learned. One interesting lesson they learned concerns rendering: They didn't want to rerender all the messages in the chat, but instead wanted to optimize it a bit by updating the chat view with only the new messages. If you are an experienced programmer, you may think, This is a premature optimization. Indeed it is! It is much more simple to pass the whole view-model to the views rather than just pass the differences from the old and new model.

Say that a programmer wants to add a new feature to a view: If the view-model is rendered by the view each time it is modified, they just need to add some properties to the model and add some code to the view to display these new properties. They don't need to worry about updating/rendering logic.

But what about performance? Isn't it bad to rerender the whole page just because the number of unread messages has changed? Here, Vue.js comes to help us. A programmer just needs to update the view-model and Vue.js will understand what has changed and will rerender only the Document Object Model (DOM) parts that actually changed. The following diagram schematizes this concept:

The lesson is this: Spend time on designing explicit, meaningful models and let Vue.js take care of the performance and rendering logic.

Since views display data from stores, you may think that a view-model is just a portion of a store. Actually, each component can have a private model that can hold values that are needed just inside the component. There is no need to put every value in a store. Stores should contain only data relevant to the application.

For example, say you want to select some photos from a list and share them. The view-model of the photo list component will contain the list of selected photos, and when a user taps on the Share button, the view-controller just needs to dispatch an action called share-photos with the selected photo list as data in the action object. There is no need to put the selected photo list inside a store.

The following is the Flux architecture summarized in a single image:

The following are some of the benefits that Facebook gained after introducing Flux to their web applications:

• Better scalability than the classic MVC
• Easy-to-understand data flow
• Easier and more effective unit tests
• Since actions represent behaviors of the application, behavior-driven development is a perfect match to write applications using Flux architecture

By adding the Vuex framework to your Vue.js application, you will experience the same benefits. In addition, Vuex, like Redux, simplified this architecture in several different ways, such as using a single store per application and removing the dispatcher from the process in favor of using the store to dispatch actions.

In this chapter, we looked at why Facebook engineers designed the Flux architecture. We focused on the fundamentals of Flux and learned that Vuex differs slightly from Flux. We can now summarize Flux in one sentence: Flux is a predictable state management system with a one-way data flow.

In Chapter 2, Implementing Flux Architecture with Vuex, you will learn the core concepts of Vuex, as well as how you can use Vuex in your applications.