Poll: Should accessor priority applied to call() like store.set()?

[ozum]

Hi,

store.get() and store.set() prioritise getters over state and actions over mutations, which is great.

Is it possible to have same prioritization feature in call()?

A simplified example:

store/product.js

const mutations = {
  ...make.mutations(state),

  ADD (state, payload) {
    state.push(payload);
  }
}

export default {state, mutations};

component

methods: {
  ...call('products/ADD')  // I expected to call `ADD` mutation when no action is available.
}

Kind regards,

[davestewart]

Hmm. On first thought, that seems like a fair optimisation.

Can you think of any situation where it would be undesirable?

[ozum]

Actually,

I don't think any undesirable situation technically, but you can leave this case open a few days for other opinions. Also if you wish, I can change the title to a question for others to participate.

I may be wrong, but intuitively I thought call() method as a component helper version of store.set() and expected feature parity between them like below:

get() <---> store.get()
call() <---> store.set()

Pros: Semantically more correct. We call a mutation or we call an action.
Cons: Method name mismatch between call and set.

Maybe another possibility is to leave call() as it is and adding set() component helper:

call() <---> ?
get() <---> store.get()
set() <---> store.set()

Pros: Method name match between set and set.
Cons: Semantically, we don't set a mutation or set an action. Confusion between set() and call() helpers.

[davestewart]

I thought call() method as a component helper version of store.set()

Well, set() is already taken by the computed helpers, so I had to come up with a name that made sense, and call did - for actions at least.

You could very easily create a helper to try this out right now if you're eager!

function call (path) {
  return function (value) {
    this.$store.set(path, value)
  }
}

You'd need to a bit more work if you want to create multiple methods using object and array syntax.

[ozum]

You could very easily create a helper to try this out right now if you're eager!

Yes, I will use that function, because it makes code cleaner.

Hope to see it implemented in vuex-pathify.

Also, I'm changing title of the case.

[hybridwebdev]

I vote leave it as is. A method name should convey intent, and I think that call implies an action, therefore it should only call an action. If you switch to it calling an action first, and falling back to a mutation you're causing confusion and also allowing people to potentially run commits in components, which is in itself bad practice.

[ozum]

A method name should convey intent, and I think that call implies an action...

Completely agree. It could be better to use set() instead of call(), but @davestewart explained why it has to be named differently: "... Well, set() is already taken by the computed helpers ..."

also allowing people to potentially run commits in components, which is in itself bad practice.

I respect and partly agree with your personal opinion and discipline not to use mutations in components, and in some cases it may be a better practice. However, I don't agree with mutations in components is a bad practice or it should be disallowed.

In current situation vuex-pathify store helpers and component helpers are in feature disparity, and all vuex-pathify generated operations are synchronous (@davestewart correct me if this is wrong). If it is a bad practice, then this.$store.set() shouldn't fallback also.

vuex-pathify is an abstraction layer, and when you use its methods, it does not matter how they do their jobs, if they do correctly. You call an action yourself or vuex-pathify method which at the end of the chain, calls a mutation nonetheless.

This is my opinion, because there is Committing Mutations in Components section in official vuex guide and there is also an official mapMutations helper to use mutations in components. Of course I may be wrong. Is there any reference about committing synchronous operations in components described as bad practice?