Skip to main content
  1. Posts/

What's the purpose of Vuex?

·679 words·4 mins
Joe Erickson
Author
Joe Erickson
Senior software developer specializing in web development, AI, and helping others learn to code.

There are a lot of things to worry about when it comes to Vue applications. You’ve got SPAs and routing and web workers and Jest and Cypress and everything else. It gets overwhelming pretty quickly. The hard part is not learning these technologies, it’s knowing what their place is in the application.

So, Vuex. What the heck is it for and why might you want to use it?

To start with, let me tell you what its function is. Vuex is a Vue addon that acts as a central data store to all the parts of your front-end application. A Vue application is composed of a lot of separate but coordinated components that, when put together, create a functioning front-end application. You might have a screen to edit users, a screen to show users, a screen to show a specific user and they all need to work together and communicate with each other to be in a useful way. Vuex can help do that by keeping all that data in one place and allowing all of these separate components to access and change it.

And that’s what Vuex can do. So what is Vuex?

Vuex is a front-end datastore
#

Vuex is a datastore that is used by all the components in an application to share data. When a component creates data, it can put it into Vuex so that other components can use it. If a component displays or uses data from Vuex, it will be updated immediately if that data ever gets updated. In other words, its data is reactive.

Vuex acts as a central place for data to live. This doesn’t mean that all data goes there. If there really is data that’s only used by a single component, that component can still have data properties all its own. But if the same data needs to be synced across multiple components, that’s where Vuex comes in.

Vuex is a single source of truth
#

You’ll see this often in the documentation. What does single source of truth mean?

I mentioned “synced across multiple components” before and that’s exactly what you don’t want to do. You don’t want copies of data in each component that you have to keep in sync between components. Imagine having each component having their own data properties that, when one changes, you had to somehow let all the others know that it changed and then copying that data between all the components. (Please don’t ever do that.)

Vuex acts as the single source to go for data. If every component knows to keep and get data in Vuex instead of individually and treat it as the source of data, that greatly simplifies your application.

Vuex is not a database
#

Nothing in Vuex is meant to be permanent. Vuex is not your database and you should not load your entire database into Vuex! Vuex is simply there to hold data that the user needs right now. Front-ends should be fast and light, so only keep in the Vuex store what the user is currently interested in seeing. If they need new information, clear the current stuff and load in the information from a separate permanent storage. And if something changes and needs to be saved to the permanent store, do that right away. Don’t wait because Vuex won’t stick around if someone leaves the page or the app crashes.

You might be wondering about offline abilities. Shouldn’t you load things into Vuex so the user can work offline?

No. That’s what Window.localStorage or IndexedDB API is for. You can tie your Vuex store to these more permanent datastores, but Vuex does not replace them. Vuex is always temporary data that your components are using right now.

So what’s the purpose of Vuex? To simplify your Vue application’s data handling. It’s there to keep all your runtime data in one place and accessible to all the components in your application. If you can learn to use this powerful tool, you’re going to make your work a whole lot easier to code and maintain.

Related

How to query your API using Vuex in your Vue application

·866 words·5 mins
Once you start using Vuex to manage the shared data of your Vue application, it becomes less clear on where or how to call your back-end API. I think everyone starts out making API calls in the created function of your component. But that doesn’t scale past a handful of components. Then, they end up loading in the same data over and over again and each component has it’s own copy, which is impossible to keep in sync. You lose the efficiency of having one part of the system in control of the data when you do that and on a larger application, this very quickly falls apart.

Should you always use getters in Vuex?

·1166 words·6 mins
One of the questions that comes up time and again concerning Vuex is “Do I always use a getter when accessing data? Or can I directly access the raw state?” It’s one of those things you hear about that you should do, but no one seems to really explain why. And do you really need to create a getter for every single piece of data that you put in the store? Isn’t that just a bunch of unneeded boilerplate and duplication?

Loading dynamic images in a Vue Component

·541 words·3 mins
When I first started using Vue, one thing I got continually wrong was how to load an image into a Vue component dynamically. At first, I found that using an absolute URL worked, but that was only useful if I was storing the images on a CDN or other external site. If I included the images in my project, as either lightweight icons or static images, then using an absolute URL, with hostname and all, didn’t really work. What about when I wanted to test some new images locally or on a dev server? Linking directly to the images in production just wasn’t going to cut it.