Value proposition of Pinia over ES modules

[franck102]

This is probably a silly question however... having been using Pinia for a while in a fairly large Vue app I am suddenly wondering what Pinia does that I could not achieve with a simple ES module that declares the Refs / computed / getters I need?

In other terms what is the difference between

//--- settingsStore.ts
export const useSettingsStore = defineStore("Settings", () => {

    const tenant = computed(() => getTenant());
    const venue : Ref<string | undefined> = ref(undefined);
    function setVenue(v : string) { venue.value = v; }

    return { tenant, venue, setVenue }
}

//--- Comp.vue
<script lang="ts" setup>
const store = useSettingsStore();
const { tenant, venue } = storeToRefs(store);
...
store.setVenue(xxx);
f(tenant.value);

and

//--- settingsStore.ts

const tenant = computed(() => getTenant());
const venue : Ref<string | undefined> = ref(undefined);
function setVenue(v : string) { venue.value = v; }

export const useSettingsStore = () => { tenant, venue, setVenue }

//--- Comp.vue
<script lang="ts" setup>
const { tenant, venue, setVenue } = useSettingsStore();
...
store.setVenue(xxx);
f(tenant.value);

I must be missing something obvious?

Thanks!

[posva]

https://pinia.vuejs.org/introduction.html#Why-should-I-use-Pinia-

[franck102]

Thanks, I had missed that page. The point about SSR and the “singleton” aspect of ES module makes perfect sense; I have a pure client-side SPA at this stage, but it makes sense to keep my options open.