Desktop Development for the Web Developer - Part 5

vite, vue 3, electron, and tailwind for desktop development

Summary

Welcome back! Haha, it has been a little while but let's get back into building our app.

It is time to cover adding state management to our app with vuex. There are certain pieces of data in our app that we are going to want to get once and then have easy access from that point on. While there are other positives from using state management, that is a good way to think about when to use it.

The Flow of Data

Some good examples of places to use it:

  • basic data on the current user
  • data that probably wont' change (list of countries, genders, etc)
  • the state of the ui (sidebar open/closed, modal shown/hidden, etc)

All these pieces of data benefit from being in one place that we can quickly grab, analyze, and/or mutate.

With that said, not everything is a good candidate to be part of our store:

  • data that is often changing
  • extremely large and complicated datasets

I don't like to store data that is constantly changing in something like vuex. To me it is just adding overhead. Instead we can put calls to the API in a service class and just use them in various components.

Large data sets also aren't a good fit for a store. Vuex is going to keep this data in memory, Let's say you have some data that is in the megabyte(s) range. That is probably not something you are going to ask the client to keep and manage.

Setup

To get vuex working with our app we are going to follow the structure that is suggested right here in the official docs.

➜ yarn add vuex@next --save

Create a directory for the store:

➜ mkdir src/store

Create the index to load the store modules:

➜ touch src/store/index.js

And put in the basic parts we will need for it to load our store modules.

Next let's create a basic module to set and get data:

➜ mkdir src/store/modules && touch src/store/modules/user.js

Our user module will be the way that we can set a user object and keep it in memory.

Usage

We are now ready to actually use our store. To let our Vue app know about it we'll alter our main.js to "use" it.

As mentioned above, stores are great for data that you are going to need to access often. User data is a good example. We'll need the id, name, etc... over and over again.

The typical pattern for getting user data would be returning it from your API when they login. Since we are just focusing on the front-end aspect of this project we can just spoof it. In our mounted method on our HomeScreen.vue component we'll call the setUserData action with a name of "Tom Cook".

Great! Now we can get the value of the user's name in our little ProfileButton.vue component and take out the hardcoded value. Using the getter we put in our store we have a nice expressive and resuable way to get the user's name. If there is some sort of translation we want to do to the name, say like capitalizing, this would be great place to do it.

Tom Cook

It is true that stores will add a little complexity to your app. If you are going something small and simple, you probably won't need it. But as a app grows both and code and the number of hands working on it, a central store's advantages become evident.

Next Up

Node and Vue Communication Communicating between the front-end and "back-end"

Reference

github repo - part 5