First pass at tracking mutation to avoid unnecessary update code - #1952 #1980
+148
−10
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.
Also tracks mutation on child refs of const declarations - #1917
This is my swing at tracking what references are actually mutated to avoid generating unnecessary update code where no mutation can occur. It does so by adding mutation tracking to the
TemplateScope
and an additional walk through the main script instance of a component. To start, only mustaches and attributes will check their dependencies for mutations and skip the update code if they don't look like they change.This does not attempt the stretch goal of hoisting non-mutating refs up out of the contextual chunk of the component because my initial naive attempt blew up the world. It turns out it's not as simple as just adjusting the hoist for
const
s to includelet
s and moving it to after the template is processed 😄.This also adds a check on the dependency tracking for expressions that will skip the
const
check if the reference happens to include more than the base member (or at least I think it does, I'm still a little fuzzy on how scoping and references are handled, but I'm getting there).There's already a TODO regarding how many times the js is walked, and this adds yet another pass through that could probably be combined with at least one of the others. It may make sense to have all the walking methods return an object of listeners for a walk with closures set up for their internal state and then run a single walk at the end that fires said closures as it goes. I didn't look at it very hard, but I promise I feel bad about adding yet another pass.