[Vuejs]-Vue – same mutation refreshes (or not!) components depending on which component it is called from?

There are a lot of problems with the code and several of them are contributing to the problems you’re seeing. A full, thorough answer that addresses all of these problems would be ridiculously long so instead I will skim through them without going into huge amounts of detail. You will need to do some further reading and experimentation to understand each of these topics properly.

Let’s start with this line in the mutation:

changedFilter = newFilterValue;

This line assigns a new value to the local variable changedFilter. That’s all. As it’s the last line of the mutation the net result is that it doesn’t really do anything.

Presumably your intent was to update the array state.report.filters, replacing the old entry with a new entry. However, just updating a local variable isn’t going to do that.

At this point you may be wondering ‘If that doesn’t do anything, then why is the state in my store changing?’. I’ll come to that in a moment but first let me prove to you that your existing code does nothing.

Try removing the code inside setFilter completely. Just leave an empty function. Then try clicking around in the UI just like you did before. You’ll find that the store state updates just the same as it did before, even though you’ve removed the code to update the array.

The correct way to implement that mutation would be to use findIndex to find the relevant index and then use either Vue.set or the array’s splice method to update the array accordingly. That will change the item in the array. However…

This brings us back to the earlier question. Why is the state updating if the mutation does nothing?

This is because you’re using the same object in multiple places. The Filter object held in the array is the same object that your UI is editing. There are no copies being taken, there is just a single object. So when you change the properties of that object inside updateOperator or updateValue this will immediately be reflected inside the store. Calling the setFilter mutation is just asking the store to replace an object with itself.

There’s nothing specific to Vue about this. This is just the standard behaviour of reference types in JavaScript. It is also common with many other programming languages that don’t directly expose pointers. It can be useful to learn a little about how pointers work in other languages as it will give you a better initial mental model before attempting to understand how reference types behave in JavaScript. Understanding the difference between ‘by value’ and ‘by reference’ may also be a useful starting point.

The next topic to cover is reactivity, which very much is a Vue topic.

Specifically, there are certain changes that Vue can’t detect. These are usually referred to as the reactivity caveats. You can find more about them in the official documentation:

https://v2.vuejs.org/v2/guide/reactivity.html#Change-Detection-Caveats
https://v2.vuejs.org/v2/guide/list.html#Caveats

There are at least two lines in your code that violate these rules:

this.operator[0] = new Operator(operatorName);

and

this.value[0] = newValue;

You can’t set array entries directly by index. The array will update but it won’t trigger any reactive dependencies within Vue. Instead you need to use either Vue.set or one of the array methods, e.g. push, pop, splice, etc.. In this example you could use splice.

e.g. Using Vue.set:

Vue.set(this.value, 0, newValue);

e.g. Using splice:

this.value.splice(0, 0, newValue);

Why does all of this matters?

Well Vue will only re-render a component if its reactive dependencies have changed. They are very similar to computed properties in that regard. Here’s how it works…

Vue compiles the template down to a function. That function is referred to as the render function. When rendering a component Vue calls the render function and that function returns a description of how to render the component. Any reactive properties that are touched while that function is running will be recorded as dependencies. If, at some point in the future, the value of one of those reactive properties changes then Vue will rerun the render function to generate a new rendering of that component.

There are two key points to take out of this description:

1. If you fall foul of one of the reactivity caveats then Vue won’t know the dependency has changed, so it won’t re-render the component.
2. The render function runs as a whole. It doesn’t just target a small chunk of the template, it always runs the whole thing.

So if you change a dependency in a non-reactive way (i.e. one of the caveats) it won’t trigger a rendering update. But if you subsequently update a dependency properly, Vue will detect that and will rerun the render function. When it runs it will run the whole thing, so any new values will be picked up, even if they weren’t detected when they changed.

It isn’t immediately clear to me which rendering dependency is causing your component to re-render. However, it only needs one of them to change in a detectable manner. Any other changes will then get pulled in incidentally when the render function runs and reads their current values.

That covers why your code isn’t working. However, I would also worry about your decision to introduce a Filter class. I understand how that may be appealing if you’ve come from some other OO environment but it isn’t typically how Vue is used. It is possible to make it work but you will need a good understanding of both JavaScript reference types and the Vue reactivity system to avoid falling through the cracks. There is no reason why using a specific class to hold your data can’t be made to work but in practice it usually ends up being less maintainable than not using such a class. A more typical Vue approach would be to use simple, anonymous objects/arrays to hold the data and then for the data owner (either a component or store module) to be responsible for making any mutations to that data. Events are used to pass changes up the component hierarchy rather than callback props.

Ultimately you will need to judge whether the Filter class is justified but it is probably not what future maintainers of your code will be expecting.