Read this before you’ll bite into Vuex.

Let’s dig in!

First of all, we want to consider why we should use Vuex?

Well, when you’ll start using it, your app will acquire a “centralized store”. ‘Heck is that?’ — you may ask. To keep it short — it’s a global store (idem per idem, right?). Aforementioned store is responsible for keeping desired information in one place (accessible from any position). Let’s say you want to store some data, for example — counter value. You can do this by passing it directly to the store.

When data reaches the store — it becomes a state. Well, what is the state, then? Essentially it’s a current working data status of the app. So we can safely say — state is a collection of data, that are intentionally stored by us. It has to be said that state is an Object!

There’s also a bit more fancier name for the state — a single source of truth. It is an implementation of information systems approach. And that is creating an object in such a way that every key for certain value is stored explicitly only once.

Why is the store global? You can trade with it from any place of your app. So, that means — all of your components will automatically gain an access to it (it has to be defined, but still)! Yes, we’re talking about dual flow of information. Your views can both, extract information and store it. Of course you decide which parts of the state will be used — a single component may have a granted access only to a chunk of the store and equivalently overwrite only certain parts of it.

Such a great thing, forget about passing a state through props! Well, I’m not saying you won’t have to pass props from time to time. But imagine that you are building an application that handles a 100 nested counters, and all of these use exactly this same value. Now you have two choices: pass a props one hundred times or store the value in Vuex.

All above implicates a predictable state — its behavior and functionality are permanent/unchanging unless it’s intentional. On the other hand, when using only props for controlling a state in our medium/large size application, one can be easily lost.

For the sake of better understanding, let’s deconstruct Vuex lifecycle. We’ll use a simple example, just to get an impression of how it works.

For the sake of this example I might use some new definitions — don’t worry tho, I’ll explain all of them in the next chapter. I do recommend to go through this chapter again after you’ll get familiar with the definitions.

Let’s assume that we operate on fully functional Vue application using Vuex — a simple counter, which displays current count and has a button to increment the value. First of all we’d like to draw the value from the Vuex, and to do this we’ll use getter. Now, undoubtedly we have a component with an event attached to it . By causing this event, we provoke a series of events. The first step in in that chain is triggering an action. This one sets off a mutation, that connects to the Vue Dev Tools. The mutation on the other hand, answers for mutating the store. This means it changes that part of state, that we use to load information about initial counter value. When we implement Vuex in Vue, we are certain, about its reactivity. So when we increment the state’s value — the new one will appear on the screen. Magic!

Now, what does Vuex offer?

First of all — getters — consider them as an application’s data extractors. Sort of computed properties. Its results will be cached an will re-compute any time, when a part of their dependencies change. You can use these to access a certain part of the state. It is worth mentioning, that you can easily use these many times, through constructing your application (such a time saver!). Of course getters are strongly bonded with mutations. Let me explain to you why.

Because there’s no state without mutations! When commited — a piece of logic, that changes the state in a foreseeable manner, is executed. Mutations are the only way to set or change the state (so there’s no direct changes!), and furthermore — they must be synchronous. This solution drives a very important functionality: mutations are logging into devtools. And that provides you with a great readability and predictability!

One more thing — actions. As it’s been said — actions commit mutations. So they do not change the store, and there’s no need for these to be synchronous. But, they can manage an extra piece of asynchronous logic!

As you can see — it all makes great sense.

What do we get from all that?

First of all — we get a pattern for storing data. A well-thought-out one.

Thanks to its structure we get a pretty effortless to understand and even easier to predict — global state. When you will get familiar with the lifecycle, and how does the pattern works with your vision of application — you feel like your code could not be easier to manage and maintain.

And of course Vuex way of processing grants us with very powerful devtools, which contains not only the list of synchronously triggered mutations, but also a couple of tweaks to with it. What you can do with that? Well, a few things. You can revert to a certain state — that is a powerful feature, that allows you to trace how things change after the mutations are triggered. Even more, you can commit chosen mutation manually and revert it as well. This comes handy when you’re working on a certain part of code and want to focus on specific migration. This way you don’t have to refresh and run through the whole cycle.

You get a single source of truth also called a global store singleton! (so you get a powerful thing, that also sounds magnificent) Why is it single — the consequences of implementation. Such a big thing. An object that is accessible through the whole application. One that will not give in when you want to change it in the other way then through mutation.

There are a few techniques of registering a store. All depending on your preferences and the size of application. I will thoroughly explain all of these in the next parts of this guide!

And of course as a result of the whole concept you get what you came for. Trivial communication between parent-child and child-child components. You do not have to pass any props or flex your mind to pass data upwards.

Just remember about a few simple, but essential rules:

1. synchronism,

2. read-only data,

3. single source of truth,

and you are ready to go! Good luck and have fun! :)