Vuex action dispatch display?

[TomKaltz]

Is there a plan to log and display dispatched vuex actions in the devtools?

[posva]

Why would you need to display actions? What affects your store are mutations. I think actions would bloat up the view for no real interest

[katien]

I think that this would be a useful feature. Most of my complex logic happens inside of actions. Each of my mutations is very simple and could be have been dispatched from one of many actions. Viewing mutations is too granular for efficient debugging sometimes.

[posva]

You wouldn't be able to time travel actions anyway

[chanon]

What would be very useful is if it would be possible to display what actions caused which mutations.

Even if it is not possible to do that accurately, just logging out the actions that occurred can help with reasoning about what caused what.

The benefit of uni directional action dispatch is reasoning about data flow. Showing this in log / debug tool is exactly what it should be used for.

[sbward]

I've been working around this by putting console.log statements in all of my actions, but I expect the devtools to have this feature so that I don't have to do it. I need this to help me reason about the flow of activity in my app (mutations alone aren't enough).

[b44rd]

Would there be other scenarios where it could be useful to pass the action name as an optional parameter of the commit function? I so, I believe a parameter like that could be used in order to see from what action a mutation gets called.

Perhaps one scenario where it could be beneficial to have another parameter to the commit function, named something like "calledBy", "callee" or sligtly more likely "action", would be to make the mutations be aware of in which context they are beeing called, and then slightly more instructed on what to do. However, displaying this in a good way inside Vue devtools seems to be a bit harder indeed, due to the asyncronous nature of actions. Some time format that includes ms might do a job though, in order to know when the action was called, and when the mutation was called.

But the question to me, seems to be weather adding another parameter to the commit function adds value or not outside devtools.

Sorry about another duplicate issue, btw. I´ll dig deeper next time indeed! 👍

[motia]

@b44d, having an optional parameter will make code complicated and probably not BC.

Perhaps we can have an alias commit function in development mode. It will log the the (action, commit) pair and call the real commit. This can be better, if actions can have a unique id to group commits they called.

[b44rd]

@motia I very much agree that cluttering the commit function with another parameter doesn´t sound like the best idea. An alias is definitely be a better alternative here, but very curious on what the core team thinks about this, as it doesn´t look like something I have seen around elsewhere yet. But, what if something like these aliases were added when compiling a development bundle?

dispatch__trace(action, payload, calledBy)
commit__trace(commit, payload, calledBy)

Both simply forward to the original function, while they in development mode also log to Vue devtools, using a (temporarily named) 'calledBy' parameter. The reason for also adding an alias for dispatch, btw, is to also be able to know from where this action is called. Was this action called from a component, a plugin, or from a lib etc.

[deini]

As @sbward mentioned:

I need this to help me reason about the flow of activity in my app (mutations alone aren't enough).

Completely agree. IMO even if we can't time travel, having a log of actions/payloads would be really useful to track the whole flow.

[ndabAP]

Would also love to see this.

[deini]

@b44rd Now that we have the ability to do this, wanna sync and give it a shot?

[b44rd]

Yes! Definetely. I believe we first need to agree on this.

Should a action debugging option be a part of the contents inside the Vuex tab, or should it be a seperate tab? @yyx990803, @posva, @deini?

I see that there´s valid reasons for both, so it´s more a matter of deciding what´s the more convenient option.

• A seperate actions tab might be a good idea, since it will not make the current Vuex tab more complex.
• Having the actions as a part of the Vuex tab, might increase the complextity of this view, but it might also be easier to see what action caused which mutations.

Opinions?

[deini]

🤔 Good points, I honestly don't know whats the best approach, it is indeed part of Vuex but not sure how we would separate mutation / actions inside of that tab.

Displaying actions and mutations on the same list might get messy, if I understand this correctly you can't go back in time with actions like you do with mutations. So we would need to have a clean separation.

[b44rd]

Started thinking about the time travel thing. When the action is called, we actually know the current state. So it would actually be possible to time travel to the state as it is before the action is does something. It doesn’t sound like a good idea to actually implement anything time travel related as a part of displaying the actions though, as it might create more confusion than it provides relevance for anything. Especially since this time travel would need to integrate logically with the existing time travel, which behaves slightly different.

What would be a nice goal to achieve though, is in my opinion two things.

1. To somehow display what params the action was called with, and at what time the action got called.
2. To somehow display whether the action caused mutations. What mutations was beeing executed as a result of the action, and at what time did this happen.

If the actions has got a seperate tab, it will be a useful usage pattern to first discover/inspect an action, see that a mutation got called, and then start to inspect the mutation.

I’d say a seperate tab will be the best starting point here. This will add usefulness for those needing to inspect actions, and it will not complicate the Vuex tab for those who don’t. What do you think?

[warent]

Agreed with the above two points. In my opinion, the absolute minimum would be:

1. Displaying the list of actions and the times they were called
2. Displaying the params the actions were called with

Bonus Feature 1. Display in a tree structure the actions/mutations within the action. If an action is called within an action, recurse. The analogy of the tree structure here is that actions are folders and mutations are files.

Bonus Feature 2. Display a snapshot of the state after each action and/or after each mutation for extra granularity.

Right now, having a list of just mutations flooding my vue-devtools is becoming less and less useful as my applications increases in complexity. Soon I may just start relying on console.log and almost entirely ignoring the vue-devtools until we can track actions.

[posva]

@b44rd I think adding this to the timeline would complexify it way too much. I feel that the important information is which actions committed a mutation. This is something that can be added to the right panel when a mutation is selected without bloating the vuex pannel.

[jeremyjh]

@posva so let it be filterable with a check-box. Coming from redux where devtools do have every action (since it has no distinction between mutations and actions in the first place) I'm very surprised at the absence of this feature.

[michalsnik]

I also think it might be a useful feature and would love to see it in action. Btw. I think we'll need a UX guy in order to not bloat devtools in future anyway :D

[idhamhafidz]

With this feature, I can easily find out which action triggers the mutation. Its really important actually

[johnleider]

During development, I often need to step through my application. Having an option to show actions would be very helpful. It doesn't need to be on by default, but the option should be there.

[gkatsanos]

• 1 for me as well.

[1337huania]

Waiting for this feature too.

[Amareis]

It will be a really useful feature. What kind of problem stops us from implementing it?

[Vic-Dev]

I'm interested in this feature. However, I would prefer to be able to see the call stack that triggered the mutation.

[yyx990803]

We will definitely implement this, however it will probably be done in coordination with the next Vuex upgrade, likely later half of the year.

[davidpelayo]

Within the Redux world, actions are viewable to guarantee developers could look at what's going on, from a higher perspective, on your SPA.

[egasimus]

+1 for this and for call stacks.

[ghost]

+1
With all the great stuff in the new release today, this is the only major feature left that I really want - particularly seeing which actions called which mutations

[anotheri]

+1

[signal-intrusion]

+1

[gkatsanos]

We will definitely implement this, however it will probably be done in coordination with the next Vuex upgrade, likely later half of the year.

Unfortunately we entered the later half of the next year and instead of pushing tools like this one and vue-test-utils which is still beta, what is pushed is the react-like-new-Vue3 api. It doesn't make sense.

[Loremaster]

Is there any update on that? It gets hard to track when you have actions calling other actions.

[WORMSS]

You wouldn't be able to time travel actions anyway

Who cares about time travel? I just want to know what happens. We don't even use mutations unless something outside of the store should be able to set those values.

[halimb]

Any news about this?

[nicooprat]

It would also be pretty useful to be able to dispatch actions right from the devtools for testing purposes.

[benwinding]

Hey guys, I was annoyed by this so I made a package to trace actions and mutations it's called vuex-trace:

import { mutationLogger, actionLogger } from 'vuex-trace'

const store = new Vuex.Store({
  state,
  mutations,
  plugins: [mutationLogger(), actionLogger()]
})

Have a go and let me know, it's based on vuex's built-in-logger-plugin

[yannxaver]

Any updates on this? Not knowing which actions have been dispatched makes debugging a lot harder, since individual mutations could have been committed from a number of different spots in the code.

[andrew-bibby]

@jan-scorl while you wait this could help you... I have added this for debugging and works well.

store.subscribeAction((action, state) => {
  console.log(action.type)
  console.log(action.payload)
})

[alectrocute]

A massive +1, oh how I've never typed "+1" so hard.

@andrew-bibby's solution is what I typically do – but my console is bloated enough, it would be great to have this be handled in vue-devtools :)

[telion2]

Just to promote this issue further:
A lot of people requested a in my opinion very useful feature for 4 years.
In my case as soon as I work on complicated vuex stores the actions are the ones that are difficult to manage, so I would almost trade them with the mutations.

What is the current status on this Issue? What would get this Issue out of "in consideration"?

[bodograumann]

Iirc, a plan for vuex 5 is to get rid of the distinction between actions and commits completely. So this feature will arise naturally from that change.