Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We鈥檒l occasionally send you account related emails.

Already on GitHub? Sign in to your account

In Ivy, @Input setting order no longer matches the order of their corresponding properties in the class #34322

Closed
Shijir opened this issue Dec 10, 2019 · 9 comments
Labels
area: core Issues related to the framework runtime
Milestone

Comments

@Shijir
Copy link
Contributor

Shijir commented Dec 10, 2019

馃悶 bug report

Affected Package

The issue is caused by package "@angular/core": "9.0.0-rc.5" with Ivy

Description

Before Ivy:
it was possible to receive @input values in a certain order. For example: I have a following component:

@Component({
  selector: 'hello',
  template: `<h1>Hello {{name}}!</h1>`
})
export class HelloComponent  {
  public name: string = "";

  @Input() set firstName(value: string) {
    this.name += value;
  }

  @Input() set lastName(value: string) {
    this.name += value;
  }
}

In this case, thefirstName input setter used to run before the lastName input setter as their order is defined in the component class. So no matter in what order users provide values to input properties, it was possible to receive them in our desired order:

<!--displays Hello JohnDoe-->
<hello firstName="John" lastName="Doe"></hello> 

<!-- still displays Hello JohnDoe as it should-->
<hello lastName="Doe" firstName="John"></hello>

After Ivy:

I realized that input values are set as they are provided in the template, not by the order of their corresponding properties in the class. For example, using the exact same component in Ivy, we get the following result:

<!--displays Hello JohnDoe-->
<hello firstName="John" lastName="Doe"></hello> 

<!-- displays Hello DoeJohn-->
<hello lastName="Doe" firstName="John"></hello>

馃敩 Minimal Reproduction

Angular 8: https://stackblitz.com/edit/angular-input-order

In Ivy: https://ivy.ng-run.com/edit/cOAOZzmer5154DINiEZT?open=app%2Fapp.component.ts

馃實 Your Environment

Angular Version:



"@angular/core": "9.0.0-rc.5" with Ivy

Anything else relevant?

@Airblader
Copy link
Contributor

Airblader commented Dec 10, 2019

I doubt that this was ever intentional, by-design behavior. This sounds like xkcd 1172 to me.

@Shijir
Copy link
Contributor Author

Shijir commented Dec 10, 2019

Lol, maybe or maybe not. That's why this issue is filed to dispel our doubts.

@zessu
Copy link

zessu commented Dec 10, 2019

Lol, maybe or maybe not. That's why this issue is filed to dispel our doubts.

yeah that's a good catch. I'll look at the calling order after the lifecycle methods to see in which order they are accessed because they seem reversed now. Is this behaviour consistent?

@Shijir
Copy link
Contributor Author

Shijir commented Dec 10, 2019

Possibly related to https://github.com/angular/angular/blob/master/aio/content/guide/ivy-compatibility.md#changes-you-may-see:

Unbound inputs for directives (e.g. name in ) are now set upon creation of the view, before change detection runs (previously, all inputs were set during change detection).

@AndrewKushnir AndrewKushnir added area: core Issues related to the framework runtime comp: ivy labels Dec 10, 2019
@ngbot ngbot bot modified the milestone: needsTriage Dec 10, 2019
@djleonskennedy
Copy link

Hmmm... hopefully I won鈥檛 see same code in my life:)

@lucipacurar
Copy link

https://stackoverflow.com/questions/5525795/does-javascript-guarantee-object-property-order

@djhojd
Copy link

djhojd commented Dec 12, 2019

Please share with us, or just me, a use case in which the order your inputs get called SHOULD matter...

@kara
Copy link
Contributor

kara commented Jan 7, 2020

@Shijir 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.

@kara kara closed this as completed Jan 7, 2020
@angular-automatic-lock-bot
Copy link

This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.

Read more about our automatic conversation locking policy.

This action has been performed automatically by a bot.

@angular-automatic-lock-bot angular-automatic-lock-bot bot locked and limited conversation to collaborators Feb 7, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
area: core Issues related to the framework runtime
Projects
None yet
Development

No branches or pull requests

8 participants