Passing the previous value to computed()
#594
skirtles-code
started this conversation in
General
Replies: 2 comments 14 replies
-
What about making the old value readonly in dev? That way it will avoid the usage of the 3 playgrounds both at runtime and build (with typescript) |
Beta Was this translation helpful? Give feedback.
13 replies
-
As a general rule of thumb, you should never be mutating anything in a computed getter - we've emphasized that computed getters should be side-effect-free, maybe we just need to be more explicit that side effects include mutating other state. |
Beta Was this translation helpful? Give feedback.
1 reply
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
This feature has already been merged into the
minor
branch of Vue core and seems likely to land in 3.4.0. But I thought it might still be useful to have a place to discuss it.The PR is here: vuejs/core#9497.
When the callback for
computed()
is called, it will now be passed the old value. That's the value it returned the last time it was run.The use case is for when the
computed()
returns an object. If thecomputed()
returns the same object, it won't trigger downstream dependencies.Some quick observations about the feature:
I do have concerns about this feature. I think it is likely to be misused.
The main problem will be that there are very tight restrictions on the legitimate use cases for the old value. Essentially, you are only allowed to use it to perform comparisons and then, conditionally, return it. If you deviate from that then things get very tricky, and I'm not sure most users will understand the nuances of what is allowed and why.
Documentation will obviously help, but I think this will be a difficult feature to document clearly. The restrictions on its use will probably come across as very arbitrary.
I also suspect that a lot of users will encounter this new feature by accident, maybe when their IDE tells them that their
computed()
is passed theoldValue
. I doubt many people will go rushing off to the docs to study the caveats associated with using thatoldValue
, it appears self-explanatory what it would be.Below I've included an example of the kinds of problems that can occur. This is split across 3 playgrounds:
oldValue
.Count
value is changed.computed()
to Playground 1, which also breaks it.The problematic
computed()
in these three examples look like this:The problems seen here are similar to the problems encountered when using a
shallowRef()
. However, withshallowRef()
there is an expectation that it is an advanced feature with lots of pitfalls. This change has introduced those pitfalls to a much more fundamental, common-place part of the API.There are various other ways to misuse
oldValue
, but what I find interesting about this example is that it seems very similar to the legitimate use cases. It also seems to work in the first example. It's not necessarily 'obvious' that it's doing something wrong.I can see how this feature might appear to be an easy win, but I think there are some downsides that need to be evaluated and it isn't immediately clear to me whether the benefits are worth it.
Beta Was this translation helpful? Give feedback.
All reactions