mirror of
https://github.com/angular/angular
synced 2026-05-24 09:28:37 +00:00
489ec15e1d
This is a deceptively simple fix for a deep issue. Consider the following template: ``` <button [title]="myTitle" [id]="(auth().identity() | async)" [tabindex]="1"> ``` `TemplateDefinitionBuilder` allocates the following variable (binding) slots: v[0] = [title] binding v[1] = [id] binding v[2] = [tabindex] binding v[3] = pipe binding v[4] = pipe binding As you can see, all three top-level property bindings were assigned variable indices. Then, variables for nested expressions were assigned. Before this change, Template Pipeline would choose the following order: v[0] = [title] binding v[1] = [id] binding v[2] = pipe binding v[3] = pipe binding v[4] = [tabindex] binding With this order, nested expressions have their variables counted and assigned before subsequent top-level property bindings. This results in different variable indices for `pipeBinding` expressions that are not inside the final property binding. However, this is not just different -- it's actually incorrect! Consider a case like the following: ``` <button [p1]="c ? (a | pipe) : 3" [p2]="b | pipe"> ``` These pipe bindings are executed *conditionally*. This means that, because we don't count and assign all the "fixed" variable slots first, i.e. those belonging to the property bindings, their indices might end up incorrect, depending on whether or not a pipeBinding happened as part of the update block. With this change, we count all variables on top-level ops first, and then descend into all expressions. PR Close #51961 |
||
|---|---|---|
| .. | ||
| global | ||
| rxjs-interop | ||
| schematics | ||
| src | ||
| test | ||
| testing | ||
| BUILD.bazel | ||
| index.ts | ||
| package.json | ||
| PACKAGE.md | ||
| public_api.ts | ||