Access $reset when using composition-style API?

[zunnzunn]

The composition-style API of Pinia has several advantages over the options-style API. One of them is the possibility to make the state readonly using Vue's readonly. The other one is that the developer gets to choose what will be publicly exposed to the outside where the store is used.

Here's an example

export const useMyStore = defineStore("myStore",  () => {
   const state = reactive({
           foo : "Hello!"
   })
    const somePrivateAction = () => { ... }
    const somePublicAction = () => { ... }
    return {
          ...toRefs(readonly(state)),  // state will be readonly outside of the store
          somePublicAction            // we did not return "somePrivateAction" so it won't be exposed
     }
}

Is it possible to access functions like $reset or $patch when using this style ? When using this style, we do not explicitly differentiate between state and actions, but I assume that Pinia can tell them apart in this case anyways, since state is reactive, while actions are not.
If this is not possible yet, here's a suggestion on how $reset and $patch could be accessed in this case:

export const useMyStore = defineStore("myStore",  (/* some parameter containing $reset and $patch here*/) => {
  ... 
}

[posva]

You can't access $patch() because it is created after the creation of the store. $reset() does only exist in option stores

[zkelo]

But how to access $patch() inside store function called from component?

[mgussekloo]

Not sure if I should make a new discussion or not, but: I wonder what the best way would be to create a $reset for use in composition stores. Or should I not even try? Thanks for pointing me in the right direction.

[kawazoe]

I am in a similar situation. I really like to use $patch in my stores, but I feel like the composition API could also be convenient for me as I could build tools that could be reused directly in components or in stores. Right now, I'm sticking to the object API, but I have some ideas to restoring those functions in the composition API, if someone would care to review them.

An idea

I initially thought it might be possible to create your own $reset, simply by creating a function that sets initial values to the state. It's not ideal... It's pretty bad, really, and it doesn't work for $patch. But, it made me think that we already have those function; we just need to have a way to compose them in... What if I told you, that solution is in the docs! :

const useXState = defineStore('x-state', () => ({
  name: ref('I am x-state'),
  other: ref('foo'),
}));

export const useX = defineStore('x', () => {
  const state = useXState();

  function doSomething(clean?: true): void {
    if (clean) {
      state.$reset();
    }

    state.name = 'should be patched';
    state.$patch({ name: 'new name', other: 'bar' });
  }

  const refs = storeToRefs(state);

  return {
    // public state is exported, private state isn't. x.$patch will only set those exports
    name: refs.name,
    // supplemental state that will not be patched by calling state.$patch, but will be patched by calling x.$patch
    unpatchable: true,
    // some action that can use state.$reset and state.$patch
    doSomething,
  };
});

Promising!

I have tried it out and, it seems like, on the surface, it is working just fine. The call to $patch updates the state as expected. Re-exported values are accessible, etc.

On the other hand, there are a lot of strange or even down right broken behaviors with this solution. For some reason, the dev tools still reports each individual set events $patch is triggering on top of the actual patch event. This is different from what I have seen in stores declared with the "traditional" API. In this case, I would expect the following timeline:

1. set:name to "should be patched"
2. patch:name+other to "new name"+"bar"

What is actually happening is:

1. set:name to "should be patched"
2. set:name to "new name"
3. set:other to "bar"
4. patch:name+other to "new name"+"bar"

Also, the patch event references two "rawEvents", like expected, but those events do not include the oldTarget and oldValue property like it does for patches issues in a store made using the traditional API.

Something is definitely behaving differently here and I am not sure that using $patch in this situation actually brings anything to the table besides noisier logging in the timeline.

Finally, it turns out that calling doSomething(true) will throw an exception stating that Store "x-state" is build using the setup syntax and does not implement $reset().; which is... well it makes sense since you never tell the store what is the "initial" value of the state like you do with the traditional API... But it could also just assume that the initial value is whatever is returned initially... So, that's a bummer.

However, we are now going full circle. You can still define your own $reset function in the x-state store to restore your refs to their initial value one by one. Again, far from ideal. You can't use $patch in that scenario. But, hey! It works. It does replace the $reset function provided by the store.

Suggestions for the maintainers ( @posva )

• It would be nice to see support for $reset on stores created using the composition method to better support this use case.
• The way the dev tools are reporting the set/patch events in this scenario is a bit strange. Can something be done about this?

[hsbtr]

The Setup Stores style needs to implement $reset $patch by itself. Here I think it is better to distinguish the two styles of APIs in the documentation.

[DonRedwoood]

The two APIs are supposed to offer the same functionality. But they clearly don't.

[angelhdzdev]

Any updates?

My attempt:

import * as actions from './actions'
import * as state from './state'

function withReset<T>(state: T) {
  const _initState: any = {}
  for (const key of Object.keys(state as any)) {
    // Any value that is not a function
    if (typeof (state as any)[key] !== 'function') {
      const item =  (state as any)[key]
      _initState[key] = isRef(item) ? item.value : item
    }
  }
  return {
    ...state,
    _initState,
    $reset() {
      for (const key of Object.keys(this._state)) {
        (this as any)[key] = this._initState[key]
       // (this as any).$patch((state: any) => state[key] = this._initState[key])
      }
    }
  }
}

export const useAuthStore = defineStore('auth', () => {
  
  return withReset({
    ...state,
    ...actions,
  })
})

Using the withReset hook to wrap the object that is returned in the setup function, I managed to add the $reset method and it works.
All actions and state have completion/intellisense, it looks type safe, reactivity is not lost, and the state is apparently reset.

The line commented using $patch doesn't work on properties that are not reactive (not ref or reactive), that's why I commented it and just mutated the store directly.

This feels "dirty" to me, and I'm wondering why the discussion on this topic stopped. 🤔😔

[thierrymichel]

This could help : Pinia: How to reset stores created with function/setup syntax