About mutations usefulness

[thelinuxlich]

What should I do inside a mutation? Can it change other store values, or should I restrict it to changing only the main value? Because if it is the latter I see a redundancy between mutations and actions, actions could access the store directly instead of reinventing the wheel calling a mutation that triggers the "true" change of state.

[yyx990803]

The difference between actions and mutations is that:

• Actions can contain async operations and dispatch multiple mutations.
• Mutations only care about actually changing the state and are always sync. So you can always compare the before/after states of a mutation once it's called.

[thelinuxlich]

Mutations care about changing the state of only one value?

[yyx990803]

It can change multiple values, but it must be synchronous.

[thelinuxlich]

Isn't this confusing? Or the convention would be for actions to be used mostly for async operations?

[yyx990803]

Why is it confusing? The doc explains it pretty well I think.

[skyrpex]

I guess he wants to trigger mutations directly?

[thelinuxlich]

Sometimes I feel like I'm writing too much boilerplate, I know that is the cost of the flux approach, but I hope some kind of convention arises that can eliminate part of this.

[ianwalter]

I think this example may be a little confusing because the actions don't really do anything other than call mutations: http://vuex.vuejs.org/en/data-flow.html

[Lokua]

I find it confusing as well. I'm just getting started but already my app seems way cleaner when only using actions. Perhaps I'm missing something, but what do mutations offer? Without looking at the source code, I feel like they are just actions with self imposed limitations (sync, not directly callable, but still callable through dispatch). Mutations would make sense to me if only through them could I mutate state, but we can mutate state through actions as well, so what's the point in using mutations at all? Are there any underlying performance benefits to using mutations vs actions?

[blake-newman]

Hey everyone. Mutations seems adds a little amount of boilerplate, and sometimes actions just simply reference the mutation.

However this comes with one huge benefit: The logic of the mutation is completely independent of any action. Thus a mutation may have a large degree of complexity, without affecting the overall complexity of the actions flow.

When it comes to debugging an issue it will help to have the flow between mutations and actions more separated. Sometimes a little more boilerplate comes with a lot of benefits, especially when is reduces the overall complexity of something. This isn't really something that is related to vuex but the overall architecture of Flux.

[yyx990803]

The whole point of a system like vuex is so that every state mutation is trackable. This is why mutations have to be sync.

Imagine you have only actions and you do this:

export function doSomething (store) {
  store.state.count++ // <- this can be tracked when this method is called
  api.callAsyncMethod(() => {
    store.state.count++ // <- this cannot, because it's async
  })
}

If you use the logger, you will see doSomething is called, but there will be additional, async state mutations happening afterwards, and when you app gets complex you will have no idea where that mutation came from. This is particularly hard to reason about when calling multiple actions with async mutations, because they can be intertwined!

Actions vs. mutations is all about separating asynchronicity from actual mutations. When you see a sync mutation in the log, you know all the side effects it can ever produce is the different between the before state and after state. But for actions, there's no such guarantee.

[blake-newman]

👍

[sergeytkachenko]

@yyx990803
I can not use mutations if I do not have asynchronous code in action?

Why mutations in first place?
Could someone just modify the state directly inside a component?

I have prepared a JSFiddle to show an example.