Often in medium to large scale web applications, developers will come across difficulties managing state across components of the application. For example, a blog might have posts on an index page, however, posts could also be used in a sidebar of recent posts throughout many different pages of the website. There became a need to access these resources from many different locations in our application, and more importantly, update the resources that would then propagate throughout. The centralized store offers what many developers refer to as “A single source of truth”. Meaning the many components using the resource are all referencing the same data. If that data changes in one component, it changes in all the components. 

A centralized store is a very powerful tool in front-end application development and is essential when dealing with hundreds of components that all work with the same data. Not all centralized store solutions are created equal, however. With React and Angular, you’ll most likely use the version of Redux meant for that framework, in Vue, you have the choice to choose Vuex, which is Vue’s implementation of a Redux centralized store. Although based on the same concept of “A single source of truth”, Redux and Vuex vary greatly, not only from an implementation standpoint but as well, from actual usage within applications. 

Overall Concept of a Store

In the above graphic, we can see that our view calls an action, which then dispatches a function to either access a piece of state in our store, or update a piece of state in our store. This is the simplest form of a central state management system. This is also what we call flux architecture. This is the basis of what both Redux and Vuex were built upon.



As with all centralized store’s, the application needs a “State”, or just a list of pieces that make up each component within your app. For example, you might have a user state, which has properties for, authenticated, user info, permissions within the app, all of the pieces that make up a “user” within your application. There could also be UI state, is the sidebar open or closed, are we viewing our messages? Did we click a toggle on the dashboard? Certain elements within our interface could change based upon the current UI state. 

Redux uses a javascript object called initialState to define the application state, the state provided below is an example of what could be in an application’s state.


Defining the state is one piece, but we need a way to trigger mutations to the state or update it. So in Redux, you would define actions for the various mutations that could take place within your application.


After we have the actions, we finally need something to actually mutate our state based on the action that was triggered. This is where reducers come into play. Reducers really just take the current state, and return a new version for whatever we’ve defined will happen according to each action.

If you’re looking at the code samples above and thinking that it looks like a lot of boilerplate just to return true or false, or update an array of posts then your heads in the right place. Redux, although widely popular, is a lot of code, for something that could be as simple as returning true or false. What we’ll see next is the Vue JS implementation of a central store, and how it’s subtle differences make it so easy to use.



Nothings changed here except we’re just calling the variable state, instead of initialState. Vuex still needs us to define what the state of the application will be.


In Vuex, getters are simply functions that just return the state value. In Redux the concept of “getters” does exist, we need a way to access the state data, however its a little more involved to set up than just defining the function.


You can think of mutations in Vuex just like Action Types in Redux, what kind of actions are possible in our application, and what function should be called when they occur.


Finally, the actions section is very similar to a Redux reducer. With the exception that we’re not using a switch to figure out what action is being called, we’ve already defined that with our mutations. 

Accessing the Store

Lets quickly look at how we could use our store within our application for both Redux and Vuex. When accessing a state value in Redux for React we would have to first tell the component that we’re accessing the store, and “wire up” the connection. We would then reference the piece of state in our store that we need. The same is true for Redux in angular, you need to create an instance of the store within your component, then using the Redux version of the getter, retrieve the piece of state.

In Vuex, anywhere in your application that you need to retrieve data from the store, you simply would type this.$store.getters.currentUser. There is no need to wire up a store, Vue handles that for you and makes the store globally available across your application.


Vue JS as a whole is really simple, easy to understand, and is a highly capable framework for a project of any size. Vuex is a great twist on the concept of Flux architecture and makes getting up and running with a central store dummy-proof. The downside to Vuex is that it’s only available in VueJS, if you’re client-side framework is React, or Angular, you’re going to be stuck with Redux. (Unless of course, you’re using something like Apollo or GraphQL). Although both offer the same general idea, one source of truth, VueJS makes the actual development very easy. 

Leave a Reply

Your email address will not be published. Required fields are marked *