Best practices for manipulating state on or immediately after read (getters)

[thebleucheese]

I'm sitting down to write a basic global notifications store for message toasts.

When the client sees a change in the state (via a subscription) the application should:

1. retrieve data from the store
2. display a toast with its contents
3. manipulate the state to shift the value off the notification array
4. check for any more notifications and continue

It's been a long time since I've done deeper front-end work with global state stores so I'm rusty on best practices, and I'm curious if patterns and practices have changed.

In my head "retrieving a value" means getter, but since I want to manipulate the state when this occurs, I'm thinking action. I can put this logic in a component - call the getter to retrieve the value and then call the action to remove it from the internal state notifications array, but it kind of feels like business logic.

Does this logic belong explicitly in the component?

Or alternatively should I write a getNextNotification() action that shifts the item off the array, manipulating the state, and then returns the value? At first glance this encapsulates how I want the client to interact with the store better, but I haven't seen examples that return state values from actions, and if I remember correctly in something like vuex with more explicit commits this may not be recommended.

[BenShelton]

There's a lot of ways to go about this, as far as best practices go you don't want to have side effects in a getter, so if you do need to have a side effect an action would be better. There's nothing wrong with returning some portion of the state at the same time as manipulating the store.
Or you could just read and manipulate the store state directly which isn't a problem in Pinia like it was in Vuex, unless you want to be very explicit by only using actions which some prefer.
Having the business logic in the consuming component is a matter of preference, personally in this case only 1 component would be reading the notifications, so to me it makes sense to keep that logic within the component itself, but keeping the logic within the store.

Here's an example of one way to implement this: https://codesandbox.io/s/pinia-vue-3-notification-hrj9h
This uses the notification store purely as a place to store the notifications, and then the Notification component has the responsibility of consuming them as it needs them, using a watch to trigger when new events are added.
There are likely better ways to do this, this is just to give an idea of how this can be achieved.

Hope this generates some ideas 😄 At the end of the day it's whatever is going to suit your needs the most, making sure the end result is easy to read, simple to test & flexible enough to make changes later.

[thebleucheese]

Cool, thanks!

For anyone interested, I put my notification handling in the App.vue for now since it's applicable to each page. I didn't encapsulate the logic in the action since it's not terribly verbose where it is. One thing I wrestled with a bit is the vue-router onComplete() callback after a router.push() event gets a bit squirrely. I think this has something to do with accessing data in the current scope or component deregistering or something.

I've also created a list of deferredNotifications[] in the toast store for things that I don't want to fire until after router state change. An example of this may be in a CRUD app adding or deleting a data item and being taken back to a list view that should display a status message regarding the success of your CRUD action. My plan is to put a watch on useRoute in App.vue and call toastStore.processDeferredNotifications() after route change. This will move notifications from deferred into the notifications queue which is subscribed to below.

App.vue

const toastStore = useToastStore()

toastStore.$subscribe((mutation, state) => {
  const nextNotification = toastStore.getNotification

  if(nextNotification !== undefined && nextNotification !== null) {
    toast.add({severity:nextNotification.severity, summary: nextNotification.summary, detail:nextNotification.detail, life: 5000})
    toastStore.removeNotification()
  }
})