Vue: Computed property not updating properly

Created on 25 Jul 2014  路  6Comments  路  Source: vuejs/vue

When I compute a value that is a conjunction of two boolean values in the data object, the result does not update when it should.

When I access the getters of the boolean values before returning the result, I get the expected value.

http://jsfiddle.net/XAbet/

Click the A and B button and notice the "A and B" value remains false. Doing the same with C and D works as expected.

Most helpful comment

Just want to point out, that this is a very old issue, and it has been fixed long time ago.
This has been working as expected at least since Vue 1.0: http://jsfiddle.net/XAbet/16/

All 6 comments

This is expected behaviour:

http://vuejs.org/guide/computed.html

See the "Dependency collection gotcha" section.

I've been bitten by that same problem and I found the real reason Vue is behaving that way: the laziness of the && operator. Indeed, in the expression x && y, if x is false it will immediately return and will not look at y; whatever the value of y, the result will be false, so there is no need to called it upon.

In the fiddle provided above, aAndB is returning this.a && this.b. Because this.a starts at false, this.b is never called, meaning Vue will not register b as a dependency of aAndB.
However in cAndD, boththis.c and this.d are called anytime the property is computed as they are first used in an assignment. Only then will it return c && d, meaning that the laziness of && will never cause us trouble.

This is one of the caveats with Vue, since it does runtime dependency getter access tracking to determine dependencies for a computed property. It means all such boolean considerations must be seperated out first into seperate variables before stringing them with a && or || operator to avoid this caveat. This does make your codebase much more long-winded than it should since you can't conveniently string the conditions into a single line. (I could easily use a Haxe macro to optionally decompose my single line of conditional expressions to multiple variable-declared conditions when i'm targeting specific environments where lazy evaluation needs to be avoided). However, the same issue can occur with an "if/else" block, requiring to pre-evaluate certain conditions if required for Vue environment.

I intially thought of "an ideal Vue" which would have a seperate JS compiler/macro-preprocessor engine that would analyse your computed function's expressions and pre-compute an AST tree (to detect any expressions for CIdent accesses, and then already precompute these bindings already for your Vue/Vue components/modules/stores. This also avoids the overhead of pre-processing dependencies with getters at runtime. However, this is easier said than done in particularly tricky cases where indirect function calls from/to different computed getters/setters, methods and even local dynamic variables, may retrieve multiple dependencies across multiple functions... It's hard to do this even with a Haxe macro and it's accompanying AST since it doesn't just retrieve dependencies via expressions, but has to infer this logically through the potential runtime assignments of such expressions. Thus, in the end (often at the cost of a bit more boilerplate), i often resort to manually listing out such dependencies manually in codebases where where it's neede for Vue to reflect on it.

Alternatively, you can always set lazy flag to false if you don't care about caching.

In the case of Javascript ahead-of-time dependency tracking is doomed to fail. You can't know in advance which property will be accessed because property names are just strings. They can be the result of arbitrary computations, including network calls.

Just want to point out, that this is a very old issue, and it has been fixed long time ago.
This has been working as expected at least since Vue 1.0: http://jsfiddle.net/XAbet/16/

@cecchi appears your comment did not age well... To those reading, this is why we summarize the solution (or screen caps) instead of just posting links.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

seemsindie picture seemsindie  路  3Comments

bfis picture bfis  路  3Comments

robertleeplummerjr picture robertleeplummerjr  路  3Comments

wufeng87 picture wufeng87  路  3Comments

fergaldoyle picture fergaldoyle  路  3Comments