Components with *ngIf are rendered before others

[Mikosko]

Which @angular/* package(s) are the source of the bug?

common, Don't known / other

Is this a regression?

Yes

Description

Currently, in our Angular application, components with *ngIf directives are being rendered before other components, leading to unexpected user experiences and potential functionality issues. This rendering inconsistency disrupts the intended flow of the application and can result in incorrect data presentation or functionality failures.

Components with *ngIf directives should be rendered in the correct order as specified by the application logic. They should only be rendered after the conditions defined in the *ngIf directive are met, ensuring the logical flow of the application remains intact.

Please provide a link to a minimal reproduction of the bug

https://stackblitz.com/edit/stackblitz-starters-awfqji?file=src%2Fmain.ts

Please provide the exception or error you saw

No response

Please provide the environment you discovered this bug in (run ng version)

No response

Anything else?

Open console in example, where you get World Hello instead of Hello World.

[alxhub]

What you are observing here is the timing of ngAfterViewInit. The view tree in this example looks like:

• (root)
  • AppRoot
    • Test(Hello)
    • EmbeddedView(ngIf)
      • Test(World)

One of the less obvious aspects of ngAfterViewInit is that it pertains to the host view of a component, not the view created for its template. Since parent views aren't considered initialized until all child views within them have been initialized, it's clear to see that Test(World) will receive ngAfterViewInit after the embedded view which hosts it is initialized, and then Test(Hello) will receive ngAfterViewInit only after the whole AppRoot component view is initialized.

[Mikosko]

What you are observing here is the timing of ngAfterViewInit. The view tree in this example looks like:

• (root)

  • AppRoot

    • Test(Hello)

    • EmbeddedView(ngIf)

      • Test(World)

One of the less obvious aspects of ngAfterViewInit is that it pertains to the host view of a component, not the view created for its template. Since parent views aren't considered initialized until all child views within them have been initialized, it's clear to see that Test(World) will receive ngAfterViewInit after the embedded view which hosts it is initialized, and then Test(Hello) will receive ngAfterViewInit only after the whole AppRoot component view is initialized.

Thanks for answer @alxhub. I tried also ngOnInit and its same behaviour, what is with your explanation of lifecycle flow expectable, but is there any "lifecycle hook" which is resolved like "capture"?

[alxhub]

ngDoCheck is executed before change detection of a child view, and thus will flow from parent to child.

However, it definitely feels like an anti-pattern to have logic which depends on the relative ordering of lifecycle hooks between components. There are almost certainly better solutions, but without knowing your specific use case it's hard to recommend a design.

[Mikosko]

I was registering Component in service on creation and I need it in order represented in DOM.

But, You are right it is anti-pattern in some way (I was also surprised by behaviour of ngOnInit).
I found better (hope proper) solution, by using @ContentChildren in parent.

Thanks for help.

Edit: I think we can close.

[angular-automatic-lock-bot]

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.}