Send previous state as the 3rd argument to store subscriptions

[emahuni]

What problem is this solving

I think the subscription feature is awesome, however it can be more versatile if it were targeted or at least revel what has changed. At least certain logic can behave differently or just sort of react to particular piece of the state.

This has always been a pain with Vuex subscriptions.

Proposed solution

onStoreStateChange (mutation, state, prevState) {
}

more like watches.

or at least allow us to do

store.$subscribe (onStoreStateChange, 'countables.inner.count')

which targets an inner prop of a state

Describe alternatives you've considered

usage of watch on the state data

[posva]

Unfortunately this is not possible because of how the state can be changed from anywhere.
There are two possible use land solutions:

• change the patch function to save the state before patching and trigger a subscription later
• add a plugin that clones the state before an action. This also restricts the functionality to actions

Another important question is what makes this crucial (rather than just conveniently)

[emahuni]

I see, so I guess watches will serve that purpose for now.

I think the crucial reason was to be able to actually see where the change happened on the whole store directly without using watches. The receiving code can then even mutate the store based on the information received. Without knowing what changed and thereby deciding what to do intelligently, we can end up creating an infinite loop if we mutate the state for some reason since it will call the sub again. A way to compare new and previous can allow us to decide on things.

The probable way of doing this would be to keep a clone of the current state in the store, whenever it changes, then emit that as the previous and pass that along with the new state to subs. Not too sure whether that should work at the low level of subs or not, but it seems dirty enough to work. If not this can be implemented at plugin level where the plugin simply takes care of this, by storing the clone in a $prevState prop in the store and then override $subscribe CB to achieve this.

[posva]

Without knowing what changed and thereby deciding what to do intelligently, we can end up creating an infinite loop if we mutate the state for some reason since it will call the sub again. A way to compare new and previous can allow us to decide on things.

Do you have a concrete example?

If not this can be implemented at plugin level where the plugin simply takes care of this, by storing the clone in a $prevState prop in the store and then override $subscribe CB to achieve this.

For performance reasons, yes, a plugin should be the one doing a deep copy.

[fvlasenko]

You could not send events key together to the events path callback
Otherwise, you have to write an extra field in the repository in order to understand what caused the change
state: () => ({ size: { path: 'size', width: 1800, height: 2500, depth: 600, cover: { path: 'size.cover', //i want to remove this field state: false, value: 100, },
events.key -> 'state', events.path -> 'size.cover'
I would like to see the full path to the parameter inside the object so that I can work with this path later

[posva]

Note events is dev only and comes from Vue