https://angular.love/en/angular-template-let-variable-hot-or-not

[giscus[bot]]

https://angular.love/en/angular-template-let-variable-hot-or-not

Angular.love - a place for all Angular enthusiasts created to inspire and educate.

https://angular.love/en/angular-template-let-variable-hot-or-not

[marekozw]

Recently I've experienced Type Narrowing problem in signal-based component and I find @let a very good workaround/solution to this issue. Let me give an example.

Im introducing TStatus generic type. It is a discriminated union with status property as a discriminator.

export type TStatus<TPayload = any, TError = never> =
  | {
      status: 'LOADING';
    }
  | {
      status: 'SUCCESS';
      payload: TPayload;
    }
  | {
      status: 'ERROR';
      reason: TError;
    };

I want to use it in my-status.component.ts component like this.

@Component({
  selector: 'my-status',
  standalone: true,
  templateUrl: './status.component.html',
  changeDetection: ChangeDetectionStrategy.OnPush,
})
export class StatusComponent {
  public readonly result = input.required<TStatus<{ hasAccess: boolean }, string>>();
}

@switch (result().status) {
  @case ("LOADING") {
    Loading...
  }

  @case ("SUCCESS") {
    Has access: {{ result().payload.hasAccess }}
  }

  @case ("ERROR") {
    Something went wrong: {{ result().reason }}
  }
}

The most important thing is that I want result input to have its type narrowed in each @case block. It should be possible even with strict template checking, since new control flow actually supports type narrowing.

But still, the code above produces an error Property 'reason' does not exist on type '{ status: "LOADING"; }'.

As it turned out, it is because type narrowing doesn't work with signals and the only way to make it work again is to "unpack" signal's value. You can do it with @if block, but in my opinion @let is perfect fit here.

Working version looks like this:

@let resultValue = result();
@switch (resultValue.status) {
  @case ("LOADING") {
    Loading...
  }

  @case ("SUCCESS") {
    Has access: {{ resultValue.payload.hasAccess }}
  }

  @case ("ERROR") {
    Something went wrong: {{ resultValue.reason }}
  }
}

Maybe in the future type narrowing will be supported in signal-based components but for now this is a solid workaround.

Please correct me and let me know, if you are aware of better way of solving this issue.

Cheers!