Best practice for updating Pinia state?

[brandonleichty]

I'm wondering if there is a best practice, or convention for updating state in Pinia.

Let's say you have some state like this:

export const useExampleStore = defineStore('ExampleStore', {
  state: () => {
    return {
      isLoaded: false
    }
  }
}

When using Vuex, I'd dispatch an action, which would commit a mutation.

My question is: In Pinia, is it still considered a best practice to update all state through actions, or is directly mutating state in components considered okay as well? Is there any convention around this?

For example:

const exampleStore = useExampleStore()
const { isLoaded } = storeToRef(exampleStore)
//This action is made up for the example
const { setLoadingStatus } = exampleStore

// Direct mutation of Pinia store
isLoaded.value = true

// VS

// Using a Pinia action
setLoadingStatus(false)

Any thoughts / advice on this is greatly appreciate. Thank you! 🙏

[posva]

It was rather a pattern than a best practice.

In pinia you don’t create an action to just change the state. You can use $patch to directly change the state. You can directly change the state in components as well.

[antoniogiroz]

but can we or should we use $patch?

[js-writer]

I have the same question. Can I do this:
isLoaded.value = true;
Or it is not allowed?

[antlionguard]

I have the same question. Can I do this: isLoaded.value = true; Or it is not allowed?

No it's allowed.

[js-writer]

Yes, I confirmed that and imho it is great!

[Made-of-Clay]

The saving grace I can think of regarding isLoaded.value = true is that it's still traceable via Vue DevTools. You can see the events and data setting to the state, so it's traceable, which I understand is the big benefit of Flux. The Flux Concepts section on Stores mentions state should be mutated by actions and changes to data should emit an event. Again, the point is to be able to track where changes come from. Pubsub made that too tough and direct state mutations via POJO changes are terribly difficult to track sometimes.

tl;dr by virtue of being able to track changes to the store's state, direct mutation seems okay at first glance, but I might still go through patch to be safe. 🤔

[js-writer]

I asked @posva on twitter and he confirmed that you can do isLoaded.value = true;
Here is a link: https://twitter.com/posva/status/1560020538281582592

[SchDen]

It looks like, for components, we should use mapWritableState

https://pinia.vuejs.org/core-concepts/state.html#modifiable-state

[Made-of-Clay]

Maybe if you're using Options API, that'll be a valuable tool for code reuse, but for Composition API, you just get the value out of the store that's returned.

[alifarabi]

you can change state from anywhere you want But keep in mind that if you keep all the updates in one place, it will be much easier to manage and maintain the code in the future.

[Made-of-Clay]

True - does this statement implicitly advocate having setter actions in the store (or some component responsible for updating the state, like a parent of shared children)?

[banavasi]

Hi I have a question on the same here, can we use computed property here to have a 2 way binding with store and state directly? The below code is in context to the options api. Thank you for this amazing plugin.

form: {
      get() {
        return useAppStore().appStoreVar;
      },
      set(value) {
        useAppStore().setForm(value);
      },
    }

[Made-of-Clay]

I don't see why you couldn't, but I also don't see why you'd need to. If you have access to the store, why not just use it directly? If it's 2-way data binding (a misnomer, really), I expect your computed looks something like this: <SomeField v-model:form="form" />

Why not just do <SomeField v-model:form="appStore.appStoreVar" />? (assuming your setup function returns the appStore var from const appStore = useAppStore())

[a0s]

import { defineStore } from 'pinia'
import { ref } from 'vue'

export const useDebugStore = defineStore('debug', () => {
  const enabled = ref(false)

  function update(value: boolean) {
    enabled.value = value
  }

  return { enabled, update }
})

How to denied store.enabled = true? I want to force using of explicitly setter update() all the time .

[Made-of-Clay]

It'd be a little weird, but you could make one internal ref state that isn't returned in the object, and one computed which is. The computed will be getter-only, so the only way to update will be the update() action.

const _enabled = ref(false); // or innerEnabled or whatever
const enabled = computed(() => _enabled.value);
…
return { enabled, update };

This way, it the dev tries to update enabled via enabled.value = true, they'll get an error from Vue.

[q-rault]

The above should work.
You could also return enabled as readonly.

    return {
      enabled: readonly(enabled),
      update,
    };