possibility to make sync use the getter instead of direct access

[mxlnk]

Hi,

currently sync intentionally accesses the state directly. I assume because of this issue https://github.com/davestewart/vuex-pathify/issues/6 ?

Would it be possible to introduce some of having it use the getter? Or is there already a way I didn't find? For me I have to write computed properties now for some syncs that I need to use getters.

[davestewart]

HI.

So you're saying:

state.value: "a"
getters.value: "AA" // some kind of transform

What happens when you want to send value "AA" back to the store?

Does state.value then become "AA" ? In which case, state.getter becomes redundant, or worse still sets up a feedback loop – value could end up being "AAAAAAAAAAAAAAAAAA...", which is why #6 exists!

Feel free to reply with a concrete use case which would make it clearer!

[mxlnk]

We additionally transform back in SET_VALUE.

Concrete usecase is:

• In the app you can choose a project you want to work on. Say there are projects x, y
• there is a setting you can change. Let's call it boolSetting
• it should be possible that these settings are different per project
• the setting should be persisted

what we currently do is:

state.boolSetting = {
  x: true,
  y: false,
}

mutations.SET_VALUE = function(state, value) {
  const project = someHowGetProject();
  state.boolSetting[project] = value;
}

getters.getValue(state) {
  const project = someHowGetProject();
  return state.boolSetting[project];
}

plugin for persisting boolSetting

We initially tried using dynamic store modules. But ended up opting for this approach since we don't knwo which projects will exist at a given point in time and this approach was easier to implement.

[davestewart]

Do you have a custom naming setup?

I ask as sync would need to reference commit('SET_VALUE') and getters['getValue'] in which case the standard or simple schemes wouldn't work.

You would firstly need this naming setup (or just name the getter the same as the state, or use direct access):

• https://davestewart.github.io/vuex-pathify/#/setup/mapping?id=custom-function

Then I would need to look at how you might do this.

What you're saying though, is that the only reason you're using getters is to use an interim function to get the project name, then just return the correct state value?

[mxlnk]

Do you have a custom naming setup? ...

Sorry, it's getters.value; so we are following the standard scheme.

What you're saying though, is that the only reason you're using getters is to use an interim function to get the project name, then just return the correct state value?

Yes. The synced value (currently just manual by having a computed property with get and set). Is then used as a v-model on a switch.

[davestewart]

OK. Let me have a think.

I'm reluctant to change functionality right now as I don't have any tests (yet). I I changed something for you then it buggers up others, that would be a real problem!

I'm using Vuex far less than I used to, so I need to get my head back in the game!

In the meantime you could move the logic outside of the store to a manual computed property.

[Timmitry]

I would also be very interested in this - we have the (I think quite common) convention of only using actions and getters to access the state. Unfortunately, sync directly uses the state. We therefore currently use computed properties with get() and set(), but this leads to unneccessary boilerplate, which we were hoping to reduce with pathify... 😕