Canonical: Marking @Input as required

🚀 feature request

Relevant Package

This feature request is for @angular/core

Description

There is a long history of discussion about whether / how to have the compiler enforce that specific inputs are provided to components: #11904 #18156 #24879 #28403 #30974

However, all of those are now closed and locked. They contain some advice about how to mitigate the problem, or kick the can down the road (“One day I hope we’ll be able to do this. That day is not today.”), but thanks to the lock-bot none of them can be used to continue the conversation, so I guess we need yet another issue, because I believe the problem still exists.

Describe the solution you’d like

It should be possible to annotate inputs such that using a component in a template without providing a value for that input is a compile-time error. Template checking has come a long way, and it’s already possible for the compiler to flag providing the wrong type as an argument. Combine with the strictPropertyInitializers flag, and such a check could rely on the existing ! assertion operator.

Describe alternatives you’ve considered

The best approach I’ve seen while reviewing the above issues is specifying the required attributes in the selector component metadata, but a) apparently that won’t catch passing null or undefined to an Input that not defined with a type that includes those values, and b) that appears to break certain test harnesses? Also, I haven’t started using strictTemplates / fullTemplateTypeCheck yet due to some problems in previous versions with narrowing on *ngIf that may or may not have been resolved – those existing capabilities may address some or all of this need.

[cyrilletuzi]

Combine with the strictPropertyInitializers flag, and such a check could rely on the existing ! assertion operator.

For information, it is what Ionic’s Stencil is doing.

[ratoi-crysty]

I’m wondering though if adding the input names to the directive selector is actually the official recommendation to achieve the goal - or rather a hackish workaround. If it is recommended - maybe it should be fixed as such in the docs?

Even if you fix the docs, and start promoting this approach, I still think it’s not ok. First, the error will be wrong, as the compiler will complain about not finding the component, instead of the desired error. Secondly, if you leave the selector, without the attribute, and use the component. You will end up in with a strange behavior. If you pass an undefined value, the compiler will complain, but if you skip the attribute, it will work, even though the runtime behavior is the same.

That’s why I think, the best approach is to treat them the same, meaning that an error should occur, similar to passing an undefined value, as that’s how the runtime behavior is.

Edit: The above example is reproducible in strict mode, I’m not sure if it works outside it.