Passing parameter to createHelpers()

[mrdavidhanson]

Great library!

Any chance it is possible to pass a parameter to the getter & mutation functions? It would be handy to pass in a value, such as a record id, in a scenario where an item in an array is being edited by a dedicated Vue child component.

const { mapFields } = createHelpers({ getterType: 'fooModule/getField', mutationType: 'fooModule/updateField', });

Thanks for your time.

[maoberlehner]

Hey @d3v0purr!

I'll look into this in the following days. Thanks for creating this issue.

[maoberlehner]

@d3v0purr could you provide a simple example of how you imagine the ideal API would be / how you'd like to use this feature? Thx!

[mrdavidhanson]

You asked a good question. Let me think this through a little and follow up.

[dasuchin]

The way I imagine using this, if I understand what he's asking correctly, would be if in my state I have an array of objects called 'projects' and I wanted to build a form to edit a single project.

Right now with this library, I don't see a way to load a form component and tell it that I want the fields from a specific project. I don't know what the feature would look like to use it, but I just don't see a way to do something like this right now and would be immensely helpful for some of the stuff I do.

[mrdavidhanson]

Sorry for my delayed response. Got consumed by another project. @dasuchin did a great job describing what I would like to see.

I suspect the most common use case would be mapping by index. This would certainly be helpful and is probably the most universal solution.

Personally, I try to avoid passing indexes around between parent and child Vue components and instead prefer supplying keys (i.e. "projectId"). This could still fit with an index-based approach provided I first have the opportunity to run my own code to find the corresponding index before supplying it to vuex-map-fields.

[greentunic]

May I ask if anything eventuated on this front?

Basically, I'm trying to access an array index, but in theory we could be wanting to pass in anything we want.

In my project, I customised the store instead, I then pass my extra parameter that I want on the store side of things in the custom getters/mutations.

An example.

Component const { mapFields: mapSomethingFields } = createHelpers({ getterType: 'get_something', mutationType: 'set_something', });

Store get_something: (state) => (field) => { var id = state.loaded_id; return state.something[id][field]; },

But this assumes I have the ID i need in the state. It would be a lot easier if I could pass a second parameter, or an object, through to the mapped getter/mutation.

Something like this? Store get_something: (state) => (object) => { return state.something[object.id][object.field]; },

[dasuchin]

I did something similar to @greentunic

I added a currentlyEditing index into my store that I set before any calls to map fields. Then extended the getter and setter to use that currentlyEditing to get/set the correct value. It seems to work pretty well.

[greentunic]

@dasuchin That's basically what I've had to do. Although it feels very bad practice to me to set a variable somewhere else before running a function. Scalability might not be great.

In the mapFields mutation function, it passes an object with "path" and "value". If we could hook into that object and add our home, including on the getter, that would solve all this.

[maoberlehner]

Thanks for providing more details! I'll look into this the following days!

[maoberlehner]

May I ask one of you to fork https://codesandbox.io/s/4rroy51z8x and build a reduced version of what you're building using the workaround you've described? Thanks!

[greentunic]

I'd be happy to once my schedule clears up a bit.

[sentriz]

I was working on one, but then the thing got stuck on "transpiling modules"

[bekliev]

any updates on this one?

[mchl18]

I could also need this... I am having a module that contains an object of objects and it would be great to update these with a helper. Right now I cannot use v-model with this sadly.