vuejs
Documentation improvement for computed property
It would be helpful if in the computed documentation for vue 2 and 3 that:
In a computed property, if you try to access a property on the instance in a branch that doesn’t run, then Vue won’t know about that dependency and won’t re-run when that dependency is assigned a new value. Link to original quote
Example
When the IF test is TRUE, if the variables contained inside the ELSE statement and their values change, the computed is not triggered. E.g. computedInSomeCases
One way to prevent this, in case you want the computed to run always, is to use the variables outside the IF statement, like in computedAlways
computed: {
computedInSomeCases() {
return this.a ? this.b : this.c;
},
computedAlways() {
const b_copy = this.b;
const c_copy = this.c;
return this.a ? b_copy : c_copy;
},
},
data() {
return {
a: true,
b: 1,
c: 2
};
}
@guska8 could you please provide more context on why such an addition would be usable? Are there cases when we care about the non-running branch if there are no side effects called in it?
could you please provide more context on why such an addition would be usable?
If the documentation doesn't mention running/non-running branches i could write code like the computedAlways example and that would lead to a higher number of execution times, inadvertedly ignoring the automatic cache benefits.
In the other hand, if the developer knows about this caveat it would write code like the computedInSomeCases example.
Are there cases when we care about the non-running branch if there are no side effects called in it?
I don't think that is.
When this issue was first opened, I had a go at adding something to the docs for computed properties explaining this. But once I'd written something, I had second thoughts about it.
As Natalia noted, a computed property should have no side effects, so the benefits are purely performance. In practice, this is very rarely going to make a significant difference.
One thing I would add is that when a computed property gets invalidated, it also invalidates downstream dependencies, such as rendering. You can see that in this example, where changing the value of b causes an unnecessary re-render:
However, that example relies on some rather in-depth knowledge of how dependency tracking works and I think it goes much too deep for the Essentials section of the docs. It also uses some pretty unrealistic code to trigger the problem: just writing everything in a more natural way will automatically fix the problem.
Even extra rendering isn't necessarily a problem in most cases. It might be a problem in specific cases, such as working with table components, but maybe that would be better covered at https://vuejs.org/guide/best-practices/performance.html rather than the docs for computed?
watchEffect() is very similar to computed() from a dependency tracking perspective. watchEffect() does lead to side effects, so it's easier to make the case for documenting this in that context. I think the key point is that Vue tracks dependencies through runtime access to properties, not through static code analysis. This is mentioned in the Reactivity in Depth guide, e.g. https://vuejs.org/guide/extras/reactivity-in-depth.html#runtime-vs-compile-time-reactivity, but that is rather buried in an advanced guide and I'm not sure the implications for watchEffect()/computed() are necessarily clear just from that explanation.
@skirtles-code I agree with you.
As a Vue newbie, I was puzzled of not having the answer to the (advanced) question "how Vue manages references dependencies in computed() properties ?"
I was able to get an answer from ChatGPT but was not able to validate this from any clear documentation from Vue docs.
Here is my discussion (with my questionings) in a nutshell :
Even if "all is supposed to work well" if you follow Vue guidelines ("don't mutate state in computed props"), it's always a good thing to offer a way to explain it.
From my POV, it would be very nice to have, on the Computed doc page, :
- a link to an "in-depth" section, covering Reactive Dependency Tracking topic
- a reference to the Computed debugging section, as I assume this may be very helpful for newcomers when they want to try & understand how computed properties work
