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

@angular/common

Description

I've recently been using Angular 12 for the majority of my Angular projects. I was previously used to non-strict mode TypeScript, which is more convenient, but it definitely allows more little issues to slip through. I appreciate strict mode, and generally prefer it, however there are some things about Angular that make strict mode extremely tedious in certain common use cases.

Notably, the async pipe can emit one of three values: undefined, null, or the type of the stream you are piping. The pipe seems to emit null, I think, as an initial value? The problem here is that it basically forces all presentational components to use inputs defined like this:

export class BasicPresenter {
  @Input() someObject?: SomeObject | null;
  @Input() someArray: SomeObject[] | null = [];
}

I rarely ever use nulls in my own code. My code usually relies on things either being undefined (not present), or defined and present. The rare case where I may use nulls is with some form fields where I explicitly want data written to a datastore on a server somewhere to actually be null, but that usually applied to properties of my entities...the entities themselves are either undefined or defined, never null.

The fact that async returns null forces me to add | null all throughout my codebase, potentially hundreds or thousands of components, which would not otherwise have to deal with null at all. It affects every stream of every kind, so even if you have streams that are basic primitives, especially streams that never have nulls in them, you still have to deal with string | null, or number | null, etc.

It should also be noted that if null is legitimately NOT a value you WANT to be allowed from a stream or to an input, the fact that the async pipe introduces it forces types to be expanded, thus potentially allowing inappropriate usage of your custom components. Further, null is not a value that will cause, say, default parameters to trigger...if you pass an input on a child component through a pipe that has parameters with default values, if the async pipe starts out with null values, and those values are passed to a pipe in the template, the defaults would not be used, null would be used instead. This in a sense makes null an infectious type that has to be dealt with in more and more code. One of the benefits of using strict mode typescript...is to make the need and use of null EXPLICIT. The async pipes expansion of the types of the Observable streams being piped eliminates a lot of this benefit for child components...and often other code they may have to consume.

For an enterprise scale project with potentially thousands of components, each of which may on average have 3, 5, 10 inputs depending on the nature of the project, that could be many thousands more instances where I have to deal with | null in my code. Its extremely tedious.

I'm honestly not really sure why null comes into play with the AsyncPipe. The API documentation doesn't mention null at all. Looking at the source code, it appears that null is the initial value for some things, when I think undefined would in fact be more appropriate.

Proposed solution

I propose that the async pipe should only deal with the explicit type defined for the Observable that is being piped. If an Observable is strictly of type SomeObject, then the type for values emitted by async should be SomeObject. By using null internally, then an expansion of the type occurs, when it could potentially be very much undesired. Expansion of the type to include null and undefined requires that downstream code deal with those values, which increases the complexity of that code.

Since the non-nullish assertion operator has been largely shunned by the community, asserting that something cannot be null is usually caught by linters and compilation is impossible without either disabling rules, or commenting them out for each use case (again, tedious and really shouldn't be necessary.) Non-nullish assertion could be used, but then if it IS appropriate that an input could potentially be undefined, non-nullish assertion cannot actually be used, and you would again be stuck adding | null to your code when its inappropriate.

Maintaining the type narrowness of the original observable seems reasonable. Observables of a particular type may never emit anything. If an observable never emits a value, then no attempt should be made to set the given property of the child component. This would avoid the need to say, initially set all inputs to null, or even undefined. There was never a value emitted by the stream, thus there would never be a value input into the child component, and no event (i.e. no ngOnChanges call) for that input.

Alternatives considered

Alternatively, if for some reason an initial value MUST be input into every child component, perhaps the async pipe could maintain the narrowest possible type of SomeObject | undefined. This would eliminate the need to add | null to every input, and instead rely solely on just adding the optional property marker ?, or defaulting the initial value of the property:

  @Input() someObject?: SomeObject;
  @Input() someArray: SomeObject[] = [];

Which comes out a lot cleaner and less tedious than including null as a valid type value.