Vuex State Management for Vue.js

Vuex is a state management pattern and library for Vue.js applications. It provides a centralized store for all components in an application, enforcing rules that ensure state mutations are predictable.

Core Concepts

A Vue application typically consists of:

• State: The source of truth that drives the app.
• View: A declarative mapping of the state.
• Actions: The possible ways the state changes in reaction to user inputs.

Vuex implements a "one-way data flow" to solve the complexity of sharing state between multiple components (such as deeply nested components or siblings) without the brittleness of prop-drilling or manual event synchronization.

When to use Vuex

• Small Apps: You may not need Vuex. A simple store pattern or standard Vue component data might suffice. Using Vuex in a simple app adds unnecessary boilerplate.
• Medium-to-Large SPAs: Vuex is recommended when you encounter complex shared state requirements that make managing state within individual components difficult or unmaintainable.

Note on Pinia

Pinia is now the official state management library for Vue. While Vuex 3 and 4 are maintained, Pinia is the recommended choice for new projects. Pinia offers an enhanced API and is essentially the successor to the concepts introduced in Vuex 5.

Inside a module's logic, Vuex provides access to both the local module state and the global root state:

• Mutations & Getters: The first argument is the local module state. In getters, the root state is provided as the 3rd argument.
• Actions: The context object provides context.state (local) and context.rootState (global).

const moduleA = {
  state: () => ({
    count: 0
  }),
  mutations: {
    increment (state) {
      // `state` is the local module state
      state.count++
    }
  },
  getters: {
    doubleCount (state) {
      return state.count * 2
    },
    sumWithRootCount (state, getters, rootState) {
      // rootState is the 3rd argument
      return state.count + rootState.count
    }
  },
  actions: {
    incrementIfOddOnRootSum ({ state, commit, rootState }) {
      // context.state is local, context.rootState is global
      if ((state.count + rootState.count) % 2 === 1) {
        commit('increment')
      }
    }
  }
}

The state management pattern is based on a one-way data flow consisting of three main parts:

1. State: The single source of truth that drives the application.
2. View: A declarative mapping of the state.
3. Actions: The possible ways the state can change in response to user interactions in the view.

Why use a centralized store?

In complex applications, multiple components often need to share the same state. Relying on props for deeply nested components or using events to sync state between siblings is fragile and difficult to maintain.

By extracting shared state into a global singleton (the Vuex Store), any component in the tree can access the state or trigger actions, regardless of its position. This provides structure and improves maintainability by separating state logic from the view logic.

const Counter = {
  // state
  data () {
    return {
      count: 0
    }
  },
  // view
  template: `
    <div>{{ count }}</div>
  `,
  // actions
  methods: {
    increment () {
      this.count++
    }
  }
}

Vuex getters are functions that allow you to compute derived state based on the store state. They act like computed properties for your store, providing a centralized way to share logic that filters or transforms state across multiple components.

Getters receive the state as their first argument. They can also receive the getters object as their second argument, allowing you to compose getters by using other existing getters.

::: warning WARNING As of Vue 3.0, the getter's result is not cached as the computed property does. This is a known issue that requires Vue 3.1 to be released. :::

const store = createStore({
  state: {
    todos: [
      { id: 1, text: '...', done: true },
      { id: 2, text: '...', done: false }
    ]
  },
  getters: {
    doneTodos (state) {
      return state.todos.filter(todo => todo.done)
    },
    doneTodosCount (state, getters) {
      return getters.doneTodos.length
    }
  }
})

Since actions are often asynchronous, store.dispatch returns a Promise if the action handler returns a Promise. This allows you to chain actions or wait for them to complete.

• Chaining with .then(): You can call .then() on the result of store.dispatch to execute code after the action finishes.
• Action Composition: An action can dispatch another action and wait for it to resolve before proceeding.
• Async/Await: You can use async/await syntax within action handlers to write cleaner asynchronous logic.

Note: If store.dispatch triggers multiple action handlers across different modules, the returned Promise resolves only when all dispatched handlers have resolved.

// Example of using async/await in actions
actions: {
  async actionA ({ commit }) {
    commit('gotData', await getData())
  },
  async actionB ({ dispatch, commit }) {
    await dispatch('actionA') // waits for actionA to finish
    commit('gotOtherData', await getOtherData())
  }
}

By default, actions, mutations, and getters are registered in the global namespace. To make a module self-contained and avoid name collisions, set namespaced: true.

When namespaced, all assets are automatically prefixed with the module's registration path (e.g., account/login). Nested modules inherit the parent's namespace unless they also set namespaced: true.

const store = createStore({
  modules: {
    account: {
      namespaced: true,
      state: () => ({ ... }),
      getters: {
        isAdmin () { ... } // -> getters['account/isAdmin']
      },
      actions: {
        login () { ... } // -> dispatch('account/login')
      },
      mutations: {
        login () { ... } // -> commit('account/login')
      },

      modules: {
        // inherits 'account' namespace
        myPage: {
          state: () => ({ ... }),
          getters: {
            profile () { ... } // -> getters['account/profile']
          }
        },
        // further nests the namespace
        posts: {
          namespaced: true,
          state: () => ({ ... }),
          getters: {
            popular () { ... } // -> getters['account/posts/popular']
          }
        }
      }
    }
  }
})