Dispatching object

[CthulhuDen]

Documentation says, the whole dispatched object gets sent to the mutation, and so do the release notes for 0.6.2, and says that

Note when using the object-style, you should include all arguments as properties on the dispatched object

But in fact only the payload field gets passed, and the arguments must be in the payload array, not as some properties. https://github.com/vuejs/vuex/blob/master/src/index.js#L83

[dddomin3]

I made a PR to fix the documentation to match the functionality you pointed to here.

[CthulhuDen]

On the second thought, it seems even worse: the payload field in the dispatched object is passed as a single argument into mutation (see the code I linked in the first post).

[LinusBorg]

On the second thought, it seems even worse: the payload field in the dispatched object is passed as a single argument into mutation (see the code I linked in the first post).

@CthulhuDen No. the payload variable will is passed to the mutation using the spread operator:

mutation.forEach(m => m(state, ...payload))

[CthulhuDen]

@LinusBorg But a few line before we see that the payload array will contain only one value (whatever the payload field was)
https://github.com/vuejs/vuex/blob/master/src/index.js#L83

[LinusBorg]

the payload is supposed to be an array. so calling dispatch may look like this:

store.dispatch({
  type: 'INCREMENT',
  payload: ['firstargument', {second: 'argument'}, 3]
})

the spread operator will deconstruct the Array and pass each item as a separate argument to the mutation. it would basically look like this:

mutations: {
  INCREMENT (state, aString, anObject, aNumber) {
    state.someString = aString // 'firstargument'
    state.someObject = anObject  // { second: 'argument'}
    state.someNumber = aNumber // 3
  }
}

Edit: I'm not saying I'm a fan of this approach, but that's how the code currently works.

I've only noticed this through this issue today and am not sure how I feel about it.

[LinusBorg]

Oh, after reading your statement in the comments of the pull request I see what you mean about [[10]] ... odd.

[CthulhuDen]

Ok maybe I'm missing something here, please bear with me.

First, you call

store.dispatch({
  type: 'INCREMENT',
  payload: ['firstargument', {second: 'argument'}, 3]
})

Then, this (https://github.com/vuejs/vuex/blob/master/src/index.js#L83) happens, so the payload is [['firstargument', {second: 'argument'}, 3]] (note: this is an array containing array)

So after https://github.com/vuejs/vuex/blob/master/src/index.js#L93 you will have this:

mutations: {
  INCREMENT (state, [aString, anObject, aNumber]) {
    state.someString = aString // 'firstargument'
    state.someObject = anObject  // { second: 'argument'}
    state.someNumber = aNumber // 3
  }
}

(note that all the payload is in array in second argument)
What am i missing?

[LinusBorg]

Yeah I got that right after I finished my comment ... don't really get what's going on there ...

[LinusBorg]

Okay, here is my assumption:

• when not using object syntax, payload will be an array because of the spread argument in the function head (type, ...payload)
• when using object syntax, Evan intended the payload to be an object, or a single string/number etc.
• therefore, when object syntax is detected, payload is wrapped in an array, so that for both scenarios, line 93/95 will work, as payload is an array either way:

mutation(state, ...payload)

Which means you were correct - when using object syntax, the content of the payload: property will arrive as one argument in the mutation.

So the current documentation is almost correct - there is only one argument after the state, but it's not the mutation object, it's the payload, and the payload should be an object that has all the properties one wants to pass.

[stealthybox]

I didn't see the discussion on this issue -- sorry @CthulhuDen.
I think your assumptions are correct @LinusBorg.
That does seem like what Evan intended.

It's a bit of a strange difference, though.
Here's my thoughts.
Ultimately, the difference is kind of hard to work with.

[yyx990803]

This turns out to be an incorrect implementation of what the doc described. Fixed and will be out in next release. It will work as described in the docs.