Home / MAD2 / Week 7

Week 7 · State management with Vuex

The one-minute story

By the end of this week you can:

• explain why shared state is needed and why prop drilling and an event bus break down;
• write a Vuex 3 store with state, getters, mutations, actions and modules;
• predict the output of code that mixes commit, dispatch, async actions and getters;
• use this.$store, mapState, mapGetters, mapMutations and mapActions correctly;
• keep an auth token in the store and survive a page refresh with localStorage;
• say when not to use Vuex, and what Pinia is.

Words you need

Idea 1: Why shared state is needed

In a small Vue app each component owns its data. Two components that need the same data can talk through props down and events up. That is fine for parent and child. It breaks when many far-apart components need the same thing: the logged-in user, the cart, the token, the notification count.

Short-lived UI bits (a dropdown open or closed, text half-typed in a field) are called ephemeral state. Keep them local. Putting everything in Vuex is a common over-engineering mistake (see Idea 8).

Idea 2: The one-way data flow

Vuex is built on a loop where data moves in one direction only:

Component --dispatch--> Action --commit--> Mutation --mutates--> State --renders--> Component
 (user click)        (async work,        (sync, the only       (reactive)         (view updates)
                      API calls)          writer of state)

Components never write to state. The only road to state is commit a mutation. The road to an async job is dispatch an action, which later commits.

Idea 3: A complete store, line by line

Vue 2 + Vuex 3 loaded from a CDN, store injected into the root instance:

const store = new Vuex.Store({
  state: {
    todos: [{ text: 'Learn Vuex', done: true }, { text: 'Write app', done: false }],
    count: 0
  },
  getters: {
    doneCount(state) {                       // like a computed property
      return state.todos.filter(t => t.done).length
    },
    summary(state, getters) {                // getters can use other getters
      return getters.doneCount + ' of ' + state.todos.length + ' done'
    }
  },
  mutations: {
    increment(state, n = 1) {                // (state, payload)
      state.count += n
    },
    addTodo(state, todo) {
      state.todos.push(todo)
    }
  },
  actions: {
    async incrementLater(context, n) {       // context has commit, dispatch, state, getters
      await new Promise(resolve => setTimeout(resolve, 1000))
      context.commit('increment', n)
    }
  }
})

new Vue({ el: '#app', store })               // injects store as this.$store everywhere

What each part receives:

store.commit('increment')            // payload missing, default n = 1
store.commit('increment', 5)
console.log(store.state.count)       // 6
console.log(store.getters.doneCount) // 1
console.log(store.getters.summary)   // "1 of 2 done"

const p = store.dispatch('incrementLater', 10)
console.log(store.state.count)       // still 6, the action is waiting 1 second
p.then(() => console.log(store.state.count)) // 16 after one second

The payload rule: one value only

commit('name', a, b) passes only a to the mutation. The second extra value is ignored. This is a classic exam trap.

// WRONG: price is lost
this.$store.commit('update_total_cost', count, price)

// RIGHT: send ONE object
this.$store.commit('update_total_cost', { count: count, price: price })
// mutation:
update_total_cost(state, payload) {
  state.total_cost = payload.count * payload.price
}

Also note the object-style commit: store.commit({ type: 'increment', n: 1 }) passes the whole object (including type) as the payload. With increment(state, n) that gives state.count += {type..., n...}, which is garbage (string concatenation). Use it only when the mutation reads payload.n.

Context versus this.$store

Inside an action the store is reached through its first argument: context.commit(...) or the destructured { commit }. Inside a component it is this.$store.commit(...). Mixing them up is the standard wrong option in "fill code1 and code2" questions: this.$store is not available inside a store action, and context does not exist in a component method.

actions: {
  send_task(context) {
    const token = Math.random().toString(36).slice(2)
    context.commit('update_final', { min: 40000, token: token })   // code1
  }
},
mutations: {
  update_final(state, payload) {                                   // code2
    state.companies.forEach(company => {
      if (company.website != null && company.capital > payload.min) {
        state.awardees.push({ name: company.name, token: payload.token })
      }
    })
  }
}

Idea 4: Mutations are sync, actions may be async

// GOOD mutation
ADD_TO_CART(state, product) { state.cart.push(product) }

// BAD mutations: async code inside
ADD_TO_CART(state, product) { setTimeout(() => state.cart.push(product), 500) }
ADD_TO_CART(state, product) { fetch('/api/add').then(() => state.cart.push(product)) }
ADD_TO_CART(state, product) { Promise.resolve().then(() => state.cart.push(product)) }

Even the third one, which looks instant, is async: then runs after the current code finishes.

state: { cart: [] },
mutations: { ADD_TO_CART(state, product) { state.cart.push(product) } },
actions: {
  addToCart({ commit }, product) {
    setTimeout(() => commit('ADD_TO_CART', product), 500)
  }
}

addItem_A(p) { this.$store.commit('ADD_TO_CART', p) },    // sync, in devtools immediately
addItem_B(p) { this.$store.dispatch('addToCart', p) },    // in devtools after 500 ms
addItem_C(p) { this.$store.state.cart.push(p) }           // bypasses mutations

Dispatch and the Promise

An action returns a Promise, so a component can wait for it:

actions: {
  async addTodoAsync({ commit }, text) {
    commit('addTodo', { text, done: false })   // runs right now, before the first await
    return 'done'
  }
}
store.dispatch('addTodoAsync', 'Learn Vuex').then(msg => console.log(msg))
console.log(store.state.todos.length)

Output: the length prints first (the commit already ran synchronously inside the async function, so it prints the new length, for example 1 if the list was empty), then done. Code in an async function runs synchronously until the first await; the .then always runs later.

Idea 5: Using the store from components

Vue.component('score-display', {
  template: `
    <div>
      <p>Current Score: {{ score }}</p>
      <button @click="boostNow">Boost Now</button>
      <button @click="boostLater">Boost After 1s</button>
    </div>`,
  computed: {
    score() { return this.$store.state.score }       // read through a computed
  },
  methods: {
    boostNow()   { this.$store.commit('increaseScore') },
    boostLater() { this.$store.dispatch('increaseScoreAsync') }
  }
})

• Read state in a computed property (so the view updates). Do not copy it once into data(): the copy would not follow later changes.
• this.$store.increaseScoreAsync() is wrong: actions are not methods of the store; use dispatch. this.$vuexstore does not exist; the name is $store.
• Every component in the tree gets $store once the root Vue instance has store (not only direct children).

The map helpers

They generate the repetitive code. Import them first: import { mapState, mapGetters, mapMutations, mapActions } from 'vuex'.

computed: {
  ...mapState(['count', 'todos']),            // this.count, this.todos
  ...mapState({ n: 'count' }),                // renamed: this.n
  ...mapGetters(['doneCount', 'summary'])     // this.doneCount
},
methods: {
  ...mapMutations(['increment']),             // this.increment(5) means this.$store.commit('increment', 5)
  ...mapActions(['incrementLater'])           // this.incrementLater(10) means dispatch
}

The spread ... is required when you also have your own computed properties: mapState([...]) alone returns an object, and without the spread it would replace the whole computed. A real question: the correct code is computed: { ...mapState(['stateA','stateB','stateC']) }. mapState expects the names that exist in the store state.

import { mapState, mapMutations } from 'vuex'
export default {
  computed: { ...mapState(['score']) },
  methods:  { ...mapMutations(['increaseScore']) }   // this.increaseScore() commits it
}

Idea 6: Getters, reactivity and the evidence-style trace

Getters are cached computed values of the store: they recompute only when the state they read changes. They are reactive, so the claim "getters are not reactive" is false.

state: { users: [
  { id: 1, name: 'Alice',   status: 'active',   role: 'admin' },
  { id: 2, name: 'Bob',     status: 'inactive', role: 'user'  },
  { id: 3, name: 'Charlie', status: 'active',   role: 'user'  } ] },
getters: {
  activeUsers(state) { return state.users.filter(u => u.status === 'active') },
  activeUserCount(state, getters) { return getters.activeUsers.length },
  adminUsers(state) { return state.users.filter(u => u.role === 'admin') }
},
mutations: {
  updateUserStatus(state, { userId, status }) {
    const user = state.users.find(u => u.id === userId)
    if (user) user.status = status
  }
}

A getter with arguments returns a function: byDone: state => d => state.todos.filter(t => t.done === d), used as store.getters.byDone(false). Such getters are not cached.

Reactivity gotchas in Vue 2

Vue 2 cannot see two kinds of change. I tested both:

// not detected: no re-render
state.user.age = 9          // adding a NEW property to an object
state.list[0] = 100         // setting an array item by index

// detected
Vue.set(state.user, 'age', 9)          // or this.$set(...)
state.list.splice(0, 1, 100)
state.user = { ...state.user, age: 9 } // replace the whole object

Declare every property in the initial state, even as null, and Vue tracks it from the start. Array methods like push, splice, pop are fine. (Vue 3 and Pinia use Proxies and do not have this gotcha.)

Idea 7: Modules, namespacing, strict mode

As the app grows, split the store into modules:

const cart = {
  namespaced: true,
  state: () => ({ items: [] }),
  getters: { count: s => s.items.length },
  mutations: { add(s, item) { s.items.push(item) } },
  actions: { addLater({ commit }, item) { commit('add', item) } }
}
const store = new Vuex.Store({ modules: { cart } })

store.commit('cart/add', 'pen')
store.dispatch('cart/addLater', 'ink')
console.log(store.state.cart.items)       // [ 'pen', 'ink' ]
console.log(store.getters['cart/count'])  // 2

• Module state is nested: store.state.cart.items.
• Without namespaced: true, mutations and actions of all modules share one global name space (names can clash). With it you add the prefix: 'cart/add', and getters['cart/count'] (bracket access, because of the slash).
• Module state should be a function if the module may be reused.
• Map helpers take a namespace first: ...mapState('cart', ['items']), ...mapActions('cart', ['addLater']).

Strict mode: new Vuex.Store({ strict: true, ... }). If anything changes state outside a mutation (for example this.$store.state.count = 99), Vuex logs the error do not mutate vuex store state outside mutation handlers. Use it in development only; it has a performance cost, so turn it off in production (strict: process.env.NODE_ENV !== 'production').

Idea 8: API calls, the token, persistence, and when not to use Vuex

Call APIs from actions, then commit the result:

actions: {
  async login({ commit }, creds) {
    const res = await fetch('http://localhost:5000/login?include_auth_token', {
      method: 'POST',
      headers: { 'Content-Type': 'application/json' },
      body: JSON.stringify(creds)
    })
    if (!res.ok) throw new Error('Login failed')       // component can catch it
    const data = await res.json()
    commit('setToken', data.response.user.authentication_token)
  },
  async fetchValue({ commit }) {
    const value = await new Promise(r => setTimeout(() => r('API Value'), 500))
    commit('setValue', value)
  }
}

Only actions should hold fetch. Mutations only assign the already-fetched data to state. In the real paper, a component does await this.$store.dispatch('fetchValue') and after 500 ms the page shows API Value.

Auth token in the store and the page refresh problem

State lives in JavaScript memory. A refresh reloads the page and the memory is wiped, so the token vanishes and the user is logged out. Fix: keep a copy in web storage and load it when the store is created.

const store = new Vuex.Store({
  state: {
    token: sessionStorage.getItem('authToken') || null     // initial value from storage
  },
  mutations: {
    setToken(state, token) {
      state.token = token
      sessionStorage.setItem('authToken', token)           // keep a copy
    },
    clearToken(state) {
      state.token = null
      sessionStorage.removeItem('authToken')
    }
  },
  actions: {
    login({ commit }, token) { commit('setToken', token) },
    logout({ commit }) { commit('clearToken') }
  }
})

After login and a refresh, the store starts again, reads sessionStorage, and the token is back in state.token. Storage facts the papers test:

Both web storages hold strings as key-value pairs: store objects with JSON.stringify and read with JSON.parse. Tradeoffs of storing tokens are in MAD2 week 8.

When NOT to use Vuex

• Small app or a page with one or two components: props and events are enough.
• Data used by one component (form fields, open/closed menus): local data().
• Data that is just a copy of the server and can be re-fetched: fetch it where needed; a cache layer is simpler.
• Using Vuex is not always hard when apps grow; the opposite: it exists to keep large apps manageable. A component can still have its own local state when Vuex is used.

const store = new Vuex.Store({
  state: { n: 1 },
  mutations: { add(state, k) { state.n += k } },
  actions: { addTwice({ commit }, k) { commit('add', k); commit('add', k) } }
})
store.dispatch('addTwice', 3)
console.log(store.state.n)

Exam radar

Quick quiz

Viva: say it out loud

Recap

Practise with real exam questions

These come straight from past papers (with the real figures and the official answer key). Open 60 real questions on this week   All Quiz 2 papers