Vuex 4 Tag

Vue JS State Management Solution

With Vue 3 gaining traction and becoming the new default, many things are changing, and the ecosystem is still shaping. Until recently, the choice for state management was clearly Vuex. But with the new composition API architecture, reactivity mechanism, and some new players in the game, the choice now might be different.

Let’s explore different ways of managing the state depending on your application size and try to predict what the future of State Management in Vue.js will look like.

Reactivity API

In options API, you can declare reactive data for a component using the data() option. Internally the object returned is wrapped with the reactive helper. This helper is also available as a public API.

If you have a piece of state that should be shared by multiple instances, you can use reactive() to create a reactive object and then import it from multiple components:

With this approach, data are centralized and can be reused across components. This can be a simple option with a minimal footprint for a small application.

Composables

A similar concept that composition API brought to the table is using a composable. This pattern, which is very popular in the React world, combined with the powerful reactivity mechanism of Vue can produce some elegant and reusable composables like the following.

Vuex 4

Pic courtesy: medium.com

Vuex is not going away. It supports Vue 3 with the same API and minimal breaking changes. The only change is that installation must happen on a Vue instance instead of the Vue prototype directly.

Vuex 4 will still be maintained. However, it’s unlikely that new functionalities will be added to it. It’s a good option if you already have a project using Vuex 3 and want to defer the migration to something else for later.

Introducing Pinia

Pic courtesy: medium.com

Pinia is a new store/state management system for Vue. This is a great tool for when wanting to share data between components in your application. One of the reasons for using a tool like Pinia (or Vuex for that matter) is that throwing events around and listening for these events in your application can easily become quite messy and unstructured. State management systems like Pinia (Vuex, Redux, etc.) can help solve this.

Pinia is now also the recommended choice by Vue and is now an official part of the whole Vue ecosystem, maintained and developed by core members of the Vue team. Last but not least, Pinia is super lightweight, only 1kb in size which is freaking awesome.

Pinia Setup Stores

Pinia supports an alternative syntax to define stores. It uses a function that defines reactive properties and methods and returns them very similar to the Vue Composition API’s setup function.

In Setup Stores:

• ref()s become stateproperties
• computed()s become getters
• function()s become actions

Setup stores bring a lot more flexibility than Options Stores as you can create watchers within a store and freely use any composable.

The state is a function that holds all the reactive data of this store and the getters are functions with access to the store as the first parameter. Both state and getters are identical to Vuex.

This statement doesn’t apply to actions. The context parameter has gone, and actions have access to the state and getters directly through their context(this). As you might have noticed, actions directly manipulate the state, which was strictly forbidden in Vuex.

Lastly, mutations are completely removed since state manipulation is now happening in actions.

All the magic is happening inside the setup function. The imported useFellowship hook is executed and returned. This will make it available to the component, including both methods and the template. Access to the state getters and actions are done directly using this object.

Of course, this component should be broken into smaller reusable ones but left like this for demo purposes.

If a different component needs to access the same state, it can be done in a similar manner.

Migrating from Vuex to Pinia

Pinia docs are optimistic that code can be reused between the libraries, but the truth is that the architecture is very different, and refactoring will definitely be required. First of all, while in Vuex, we had one store with multiple modules, Pinia is built around the concept of multiple stores. The easiest way to transition that concept to be used with Pinia is that each module you used previously is now a store.

Actions no longer accept context as their first parameters. They should be updated to access state or any other context property directly. The same applies for rootState, rootGetters etc. since the concept of a single global store doesn’t exist. If you want to use another store you need to explicitly import it.

It’s evident that for large projects, migration will be complicated and time-consuming, but hopefully, a lot of boilerplate code will be eliminated, and the store will follow a more clean and modular architecture. The conversion can be done module by module rather than converting everything at once. You can actually mix Pinia and Vuex together during the migration so that this approach can work.

For more information and to develop a website using Vue.js, Hire Vue.js Developer from us as we give you a high-quality product by utilizing all the latest tools and advanced technology. E-mail us any clock at – hello@hkinfosoft.com or Skype us: “hkinfosoft”.

To develop a Website using Vue.js, please visit our technology page.

Content Source:

1. medium.com