0👍
My view (opinion based), is that the more verbose way is the correct way. When you use the vue dev tool, seeing the mutation by name helps with debugging. However in cases where I’m updating an object with many params, I have used the later.
0👍
The real question is whether that logic belongs in one mutator method or if it should be re-factored out into separate methods. For me a mutator called setMaterialItem should mutate the state of a property called materialItem, but it actually looks like it does a bunch of other stuff on an object called order_material, how you counteract that depends on exactly what you are attempting to do, maybe you need to use an action or maybe break your store in to modules, perhaps a mixin would allow for better code reuse, it’s difficult to say without having a more detailed idea about how your app is structured.
While principles like DRY are great for guiding your development, remember it’s just as important that your app is logically structured, is easily maintainable and makes sense to you, then you can cut yourself a bit of slack when your code isn’t perfect.