Support some of the triggers from @defer for the @if block

[rosostolato]

Which @angular/* package(s) are relevant/related to the feature request?

core

Description

Maybe not all defer triggers make sense for the if block, but some of them yes. For example the on viewport trigger, you could only render a component once it enters the viewport. That's perfect for a virtual scroller implementation.

Proposed solution

@for (item of items; track item.id) {
  <div #container [style.height.px]="500">
    @if (on viewport(container)) {
      <app-heavy-component [item]="item" />
    }
  </div>
}

Alternatives considered

If it's not possible to bring those triggers to the if block, at least we could add another section to defer just like prefetch to let you destroy the component.

@for (item of items; track item.id) {
  <div #container [style.height.px]="500">
    @defer (on viewport(container); destroy on viewport(container)) {
      <app-heavy-component [item]="item" />
    }
  </div>
}

It could be:
destroy on exitViewport(container)
destroy on exit(container)

Or anything else that makes sense.

[jessicajaniuk]

This isn't a 100% duplicate, but it's essentially the same as #53185. It's likely we wouldn't support these blocks directly on @if and @for, but we are considering other abstractions that would solve for this case.

[pkozlowski-opensource]

Agree with @jessicajaniuk - I don't think it is reasonable to embed many of the possible show / hide conditions directly in the control flow. We should rather expose a service / directive / signal that flips data model depending on a given element being in the viewport or not.

[pkozlowski-opensource]

Closing based on the above reasoning.

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