$reset for composition API stores

[JollyBrackets]

In reference to #1012, the $reset method is not available on stores using the composition API.

This solution on Stack overflow proposes an elegant way on how to do this using a plugin:
https://stackoverflow.com/questions/71690883/pinia-reset-alternative-when-using-setup-syntax

We have build something similar as a Nuxt plugin:

import type { Pinia, PiniaPluginContext, PiniaPlugin } from 'pinia'
import cloneDeep from 'lodash/cloneDeep'

const extendStoreMethods: PiniaPlugin = (context: PiniaPluginContext) => {
  const { store } = context
  const initialState = cloneDeep(store.$state)
  const initialKeys = Object.keys(initialState)

  store.$reset = () => {
    store.$patch((state: Record<string, any>) => {
      Object.keys(state).forEach((key) => {
        if (initialKeys.includes(key)) {
          state[key] = cloneDeep(initialState[key])
        } else {
          delete state[key]
        }
      })
    })

    store.$dispose()
  }
}

export default defineNuxtPlugin((nuxtApp: any) => {
  const pinia = nuxtApp.$pinia as Pinia

  pinia.use(extendStoreMethods)
})

Is there a reason why we should not use this?
If not, would this be a good addition to Pinia itself?

[posva]

Depending on what's on the state (Classes, Dates, circular references) and the method used for cloning, this method might not always work. Calling the function state() like in option stores always works.

$reset() is not that common to use. I personally never use it in my projects because I rarely need to reset a store. I might need to reset some values but rarely the whole store. But the real reason this is not in Pinia is to keep Pinia as lean as possible (1.5kb)

[JollyBrackets]

Thanks for the reply! Good point on the complex objects! So you mean to say instead of using:

const initialState = cloneDeep(store.$state)

we should do something like this?

const initialState = store.state()

We rely on resetting quite heavily when switching between "projects" in our app.

[posva]

Could you share the store code related to that resetting feature and what makes it essential to your case? I rarely see it as a useful feature but quite some people seem to like it so I would like to understand some of the usecases people use it for and see if I should add a cookbook entry for it.

[hymair]

@posva In an app where you can switch the currently active entity and the entity has it's own context and resources, you want to reset any stores that are holding entity-specific data.

For example a user controlling many companies and each company has it's own data that needs to load, which we keep in stores. Those stores need to be reset when switching companies.

[posva]

I would use one store to have all the data and maybe create composables that can take in arguments to call the store with specific arguments.
In my experience over the past years, creating one store per entity is more of a bad practice

[hymair]

In our case, it's a very large scale accounting app. User is able to switch between many companies. Each company has ~25 subresources like contacts, accounts, etc. Each of these resources has its own store because we're handling fetch promises, loading states, computed vaues, methods for fetching/updating/deleting and so on.

Whenever user selects a different company, we are resetting all these states.