As Vue’s popularity amongst developers and established organizations continues to grow, you’ll likely find more opportunities to develop single page applications in the self-proclaimed progressive front end framework. Along with the growth in popularity, another important aspect to continuously grow is your understanding of Vue and its inner workings and core packages, such as Vuex. Vuex is the central state solution for Vue developed and maintained by the Vue core team, which makes it the official solution for central state management in Vue applications. I’d like to take a moment to touch upon some advanced patterns and a few tips to get everyone on the same page when it comes to delivering highly functional clean code when integrating Vuex into their new or existing Vue project.
The first tip for cleaner code when using Vuex is making sure you’re not overusing getters. You should think of getters like computed properties on your components, if you’re not computing something, you don’t need a computed property and can instead use the data. Same goes for getters, if you’re not doing any calculation or filtering out something in a piece of state to return, you should instead access the store state directly and avoid the unnecessary getter that solely returns a piece of state.
In portions of your application that have associated pieces of state that get updated on your front end, it might be tempting to create methods that solely dispatch an update to your store. In certain cases that may be a valid way to update your store, but what if you use computed properties with set functions that call a mutation to directly update the value in your store? In doing this, as soon as the data is changed on the front end, the setter portion of the computed function immediately updates your store by dispatching a mutation.
Commit vs Dispatch
It might be tempting to always think you need to dispatch actions, other frameworks teach us that dispatch is the sole way to interact with our central store. But in Vuex, you can directly use commit, and you should. You should avoid creating boilerplate actions that solely commit the data passed to them. Similar story to the getters, if you’re not doing anything special in the dispatch, use commit instead.
In some cases, you may find yourself with data in your application that needs to be updated when other data gets updated. In these instances, what you could do, is dispatch the action that fetches the parent data, chaining on a
.then function to dispatch the action for the child data once the parent data has been fetched. Instead, what you could do, is move this same logic to your parent action itself. Now you only need to dispatch one action, and that action will chain the child-related data right from within your store.
These simple changes can make a big impact on your application, no matter the size.