Input parameter order does matter

After updating from 8th to the 10th version, the input parameter order does matter.

🐞 bug report

Affected Package

The issue is caused by package @angular/core

Is this a regression?

Yes, the previous version in which this bug was not present was: 8th version

Description

In case the Input decorator is used on a setter and a parallel input parameter is used inside the setter, this parallel parameter is not available during the setter execution.

🔬 Minimal Reproduction

https://stackblitz.com/edit/angular-ivy-parameter-order-bug?file=src%2Fapp%2Fapp.component.html

🔥 Exception or Error

Error: cannot read property 'bla' of undefined

🌍 Your Environment

Angular Version:

10.2.3

Anything else relevant?

[alxhub]

It seems that in ViewEngine (i.e. Angular v8) the inputs were evaluated in alphabetic order.

This isn’t actually the case. I think there’s an issue with your stackblitz examples. The a setter is defined as:

  @Input() set a(v) {
    this.text = `A: ${this.a}; B: ${v}`;
  }

this.text includes two values here, both of which are values for a (unlike what the B: label implies). Really it’s showing the value before and after the binding is evaluated, which will predictably be undefined and then the singular incoming value.

In actuality, in View Engine bindings were set in the order of @Input field declaration in the directive/component being consumed. This wasn’t a chosen or specified behavior, merely an implementation detail of how the inputs were captured when iterating members of the directive class.

Despite being rather arbitrary, this ordering does intuitively make a certain amount of sense. It’s stable and well-defined, and doesn’t vary from consumer to consumer. If one input’s setter consumes the value of another input, developers tend to naturally write the declaration for the dependency first, and then its consumer. A lot of the time then, this approach just “worked”.

The Ivy design initially leaned towards following the ordering at the template usage site instead. This was favored for two reasons:

1. Ivy’s locality principle meant that knowledge of the declaration ordering of bindings wasn’t available, meaning that VE’s behavior could not be emulated.
2. Another general principle was to treat the template as code, and evaluate it start-to-finish exactly as the user wrote it. A major goal was to have source mapping of templates good enough such that one could step through the HTML in a debugger, and it’s much more natural to jump through bindings in the left-to-right order that they’re written.

In practice, this constraint proved overly restrictive. We realized it would limit our ability to optimize templates down the road, and decided that like View Engine, Ivy would not commit to a particular import binding order. I believe the decision at the time was:

• From element to element in the template, bindings will always be evaluated in template order. That is, when the template says:

<foo [a]="..."></foo>
<bar [b]="..."></bar>`

The [a] binding will always be evaluated/set before the [b] binding.

• Within an element, the order is unspecified. The template compiler is free to reorder bindings as it sees fit. For example, in the template:

<foo [a]="..." b="..." [c]="..."></foo>

The template compiler may evaluate both [a] and [c] before b, in order to chain the binding instructions and generate a smaller template:

property('a', ...)('c', ...);
attribute('b', ...);

[dopusteam]

Assuming that this is not an expected regression (I don’t see it in the breaking changes for ivy), then it could be resolved in the Ivy compiler by sorting inputs before generating instructions, I believe.

Well, I hope nothing changed since this comment 😃

To answer your question, we don’t consider input setting order within directives to be public API. If you want to react to a directive’s inputs in a certain order, using the ngOnChanges lifecycle hook tends to be a better place. As such, I’m closing this issue as working as intended.