When to use Pinia with Laravel and Inertia

Pinia shows up on most Vue job posts, so people add it to a new Laravel app on day one. Then the post list lives in two places and one of them is stale. Here is the line between page props and a store, and how to install Pinia on the starter kit without breaking SSR.

An Inertia page already receives its data as props. Copying the post list into a store gives you two sources of truth and a stale screen.

Use Pinia for state the server does not own.

What stays in props#

The CRUD guide loads posts in the controller and types them with defineProps. Search lives in the query string. After a save, the redirect renders the index again and the list is fresh.

That is the server state. Do not router.reload into a Pinia store “so every component can read it.” Pass the prop, or read a shared prop Inertia already keeps. A store that mirrors Eloquent will be wrong the moment someone else creates a row, unless you also build the Reverb path to patch it.

What belongs in a store#

A draft title the author typed on /posts/create, then lost by opening the list, is client state. So is a command palette that is open, or a multi-step wizard you have not turned into URLs yet.

Install it on the starter kit#

npm install pinia

The Vue starter kit mounts Inertia in resources/js/app.ts with withApp. Add Pinia inside that callback, and create the instance there, so a server render does not reuse another request’s state. Keep the title, layout, progress, and focus directive the file already has.

import { createPinia } from "pinia"; 

// inside the withApp callback resources/js/app.ts already has
withApp(app) {
  app.use(createPinia()); 
},

A draft store#

import { defineStore } from "pinia";
import { ref } from "vue";

export const useDraftStore = defineStore("draft", () => {
  const title = ref("");
  const excerpt = ref("");

  function clear() {
    title.value = "";
    excerpt.value = "";
  }

  return { title, excerpt, clear };
});

<script setup lang="ts">
import { useDraftStore } from "@/stores/draft";

const draft = useDraftStore();
</script>

<template>
  <input v-model="draft.title" name="title" />
  <textarea v-model="draft.excerpt" name="excerpt" />
</template>

v-model is justified here because the store is the source. The <Form> component in the CRUD guide does not need it: the browser owns the inputs until submit. Use the store when leaving the page should keep the text.

Vue Router apps#

A separate SPA from the Sanctum guide has no Inertia props. Pinia is a normal place for the current user after GET /api/user, and for data you do not want to refetch on every route. Still treat the API as the source. Write the response into the store. Do not let the store be the only copy of a record you have not saved.

Vuex is the old answer. New Vue 3 code uses Pinia. The starter kit does not install either until you do.

Recap#

• Page props are your server state; don’t copy them into a store.
• Pinia holds client state the server doesn’t own and a refresh may forget.
• Install it inside withApp so SSR requests don’t share a store.
• In a Vue Router SPA, Pinia can cache API responses, but the API stays the source.

FAQ#

Next steps#

• Build a CRUD with Laravel, Inertia and Vue: server state in props.
• Server-render an Inertia app: why the store is created per request.
• Authenticate a Vue SPA with Sanctum: Pinia in a Vue Router app.
• Pinia docs

Sources#

• Pinia: Getting started
• Pinia: Server-side rendering
• Inertia v3: Client-side setup