[DONT BACKPORT][BUGFIX lts] Ensure hash objects correctly entangle as dependencies v2 #19584
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is an alternative to #19583
The previous bugfixes to
{{hash}}
caused a change to the semantics ofcomputed properties that depend on a hash. Specifically, because
{{hash}}
objects are now proxies, they are constant, never updatingagain after they are initially created. This is fine if you depend on
an individual key in a hash, but breaks if you depend directly on the
hash itself:
This is used occasionally when you wish to depend on the dynamic keys
of a dictionary, like so:
Notably, this is not a problem with autotracking, because autotracking
will entangle the usage of these keys dynamically. So this is only a
problem with legacy systems such as
computed
andobserver
whichcannot dynamically add dependencies based on the function's runtime.
To fix this, we need to determine if a dependency is a hash when a
computed or an observer depends upon it, and then entangle all of its
keys if it is. We do this whenever the value is the last value in the
chain.
This PR/fix ended up not working out, so we're not backporting