The State of Vue State Management

You’ve now seen how to build Vue.js applications and have begun to string together multiple different components into your first set of real applications. As the size of your application grows, so does the complexity. In this chapter, it’s time to take a look at how you can begin managing that complexity by integrating state management.

Here, you’ll begin by taking a look at how problems with states arise, how state management can help address it, and what features Vue.js 3 has to help you deal with it directly. You’ll learn this while building a simple profile card application that uses multiple components between which the state needs to be synchronized. The next chapter will introduce a tool to further help with this, called Pinia.

So, in this chapter, we will cover the following topics:

• Understanding the component architecture and the problem of the state
• Holding the state in a common ancestor component...

Technical requirements

There are no technical requirements for this chapter outside of the npm CLI you have previously used to scaffold applications with Vue.js.

You can find this chapter’s source here: https://github.com/PacktPublishing/Frontend-Development-Projects-with-Vue.js-3/tree/v2-edition/Chapter09

Understanding the component architecture and the problem of the state

In previous chapters, we have seen how to use a local state and props to hold the state and share it in a parent-child component hierarchy.

Now, we will begin by showing how to leverage state, props, and events to share states between components that do not have a parent-child configuration. These types of components are called siblings.

Figure 9.1 – Child 1 and Child 2 are “sibling” components

Throughout the chapter, we will be building a profile card generator app that demonstrates how the state flows down the component tree as props in an application, and how updates are propagated as backup using events, event buses, and store updates.

Given that we want to build a profile card generator, we can break the application down into three sections: a header, where we will have global controls and display the title of the page; a profile form, where we will capture...

Holding the state in a common ancestor component

To only hold the state with the state component and props, and update it with events, we will store it in the nearest common ancestor component.

state is only propagated through props and is only updated through events. In this case, all the state components will live in a shared ancestor of the components that require them. The App component, since it is the root component, is a good default for holding a shared state.

Figure 9.3 – Common ancestor component holds state with props and event propagation

To change state, a component needs to emit events up to the component holding our state (the shared ancestor). The shared ancestor needs to update state according to the data and type of events. This, in turn, causes a re-render, during which the ancestor component passes the updated props to the component reading state.

Figure 9.4 – Updating a sibling component...

Adding simple state management

For our simple application, we can replace a lot of the boilerplate code if we use the reactive() API to build a simple store:

1. Let’s start by building a new file, store.js, that uses a reactive object for our profile values:

   import { reactive } from 'vue';
   export const store = reactive({
     name:'',
     occupation:''
   });

This very simple object will be very powerful due to the use of Vue 3’s reactivity support. Any component making use of the values from here will be able to rely on knowing that when a value changes, it will instantly be reflected. Right away, we can see how this simplifies things as we switch to the store.

2. In AppProfileForm, let’s import the store first:

   <script setup>
   import { store } from '@/store.js';
   </script>

3. Next, update both fields to point to the store instead of local data. In the following code, the v-model value...

Deciding when to use a local state or global state

As we have seen through the examples, the Vue.js ecosystem has solutions for managing shared and global states. What we will look at now is how to decide whether something belongs in a local state or global state.

A good rule of thumb is that if a prop is passed through a depth of three components, it is probably best to put that piece of state in a global state and access it that way – so for example, a value goes from a parent to a child, and then on to a grandchild. This could also apply to two siblings and a parent, with three components but less depth.

The second way to decide whether something is local or global is to ask the question when the page reloads, does the user expect this information to persist? Why does this matter? Well, a global state is a lot easier to save and persist than a local state. This is due to the nature of a global state just being a JavaScript object as opposed to a component state, which...

Summary

This chapter was an introduction to the state management landscape in Vue.js. Throughout this chapter, we have looked at different approaches to shared and global state management in a Vue.js application.

We began by looking at storing a global state in one shared ancestor. This allows data sharing between sibling components through props and events. While this works, it does require extra code to handle the architecture of passing around data.

You then used Vue’s built-in reactivity to create a simple, shared store. This resulted in a much simpler application, as much of the code from the previous version was able to be removed.

Finally, we have had a look at what criteria can be used to decide whether a state should live in a local component state or a more global or shared state solution.

The next chapter will be a deep dive into writing large-scale Vue.js applications with the new recommended way of handling shared state, the Pinia library.

...