Missing types in subscribe's mutation.events

[maximelebreton]

Hello, and thanks for your work on Pinia!

Everything seems to be correctly typed, except the mutation.events:

With this example:

interface State {
  selectedInput: number | null;
}

export const useStore = defineStore("main", {
  state: (): State => ({
    selectedInput: null
  }),

useStore().$subscribe((mutation, state) => {
  mutation.events.key // ==> Typescript Error: Property 'key' does not exist on type 'DebuggerEvent | DebuggerEvent[]'.
  mutation.events.oldValue // ==> Typescript Error: Property 'oldValue' does not exist on type 'DebuggerEvent | DebuggerEvent[]'.
}

If i try to call mutation.events.key, I have the Property 'key' does not exist on type 'DebuggerEvent | DebuggerEvent[] Typescript error, and it should not?
So I need to add //@ts-ignore in top of lines to prevent building fail, and I haven't the autocompletion.

Why can't you infer these types, as they're based on the State type?

Thanks!

[spixy]

Also documentation of mutation.events says "DEV ONLY", what does it mean?

[JoshuaDoshua]

It looks like these debugger events are only loaded through a DevtoolsPlugin?

Having the previous state (similar to core vue watches) would be very useful in a $subscribe

[miraclebg]

I've lost almost 8 hours until i found out this post... and figured this issue too...

Yeah.. it would be good to have this feature in production too!

[posva]

mutation.events is a feature that is only available during development, it won't work in production. It comes from vue watchers (https://vuejs.org/guide/extras/reactivity-in-depth.html#component-debugging-hooks). It's only safe to use this information for devtools plugins .

The reason of your error is actually unrelated to this: the type of mutation.events is DebuggerEvent | DebuggerEvent[], it's sometimes an array, sometimes one single event, that's why you can read mutation.events.key, you need something like Array.isArray(mutations.events) ? ... : mutations.events.key

[kub1x]

+1
I used _mutation.events to determine what part of state I have to sync to server and now in prod it won't work showing it's always undefined. I prefer having this information in prod too in some form, otherwise I have to keep the whole state twice, the second being how it was stored on the server. Then I have to compare the two states each time a mutation occures, to figure out what changed since last sync.

[frammkor]

Oh, that's a shame. It was a very useful feature. I will need to build a workaround to listen to the type of change in my store.

[mrehacek]

Please explain it in the docs.

[pipwerks]

@posva Pinia is great, it makes states in Vue so much easier to manage. Thanks for all your work on it. But I fell into the same trap -- I have a lot of logic that follows this structure:

myStore.$subscribe((mutation, state) => {
  if (mutation.events.key === "foo") {
    //do something related to foo
  }
}

The docs didn't make it clear that we shouldn't do this. What is your recommendation for a production-friendly way to target specific changes via $subscribe without using mutation.events.key?

Thanks!

More context: I my scenario, I have a SPA with a lot of reactive form fields. If one form field changes, the application logic requires other form fields to also update (for example, changing all field values from inches to millimeters). Using $subscribe with specific event handling via mutation.events.key works great. If we're not supposed to use mutation.events.key in production, how would we go about targeting specific changes within the state?

[nzmattman]

this is such a useful feature, why it isn't in production is a bit baffling

[zanzara]

Yes, pls. Add this also to production mode!

I've been also caught in this trap now. Very disappointing 😞

[posva]

As noted, this cannot be ported to production because it comes from Vue. One could implement a custom Proxy-based tracking plugin to have this information but it's out of scope of Pinia.

The original question isn't even about the events being dev only (as documented). The only thing left to do is to deprecate events and rename it debugerEvents to further emphasize the dev-only nature of this property