feature request: mark component @input as required (vs none if not required)

[born2net]

[ ] bug report => search github for a similar issue or PR before submitting
[x ] feature request
[ ] support request => Please do not submit support request here, instead see https://github.com/angular/angular/blob/master/CONTRIBUTING.md#question

Current behavior
no way to enforce which are a component's required interface

Expected behavior
get a TypeScript error that component is not satisfying it's minimum interface ti work

What is the motivation / use case for changing the behavior?
I have a VERY complex component with 6 inpits, yet only 1 input is required for it to work with no errors. If I will want to re-use in in 6 months, no way will I remember what is the min input interface. Same for new users of my component.

• Angular version: 2.0.X
  latest ng2

this is not a breaking change as current inputs (none req, can be left as is) so would be awesome if can be added in a minor release update.

Angular 2 Kitchen sink: http://ng2.javascriptninja.io
and source@ https://github.com/born2net/ng2Boilerplate
Regards,

Sean

[vicb]

I don't think there is anything we could/should do in Angular.

It is mostly about your component documentation.

[born2net]

I disagree. Code should be self documenting and self correcting.
Implementing something like this can be trivial via typescript checker or even JIT checker.
Even Alex Rickabaugh on Gitter, please reconsider.

regards

[born2net]

Victor please open the issue as this at least merits a discussion (and if Guru Alex agrees, I think it can be investigated)..

regards

Sean.

[zoechi]

I'd just throw an exception if mandatory input values are not provided.

[born2net]

ya that's what it does now, but I think it would be super cool if the framework enforced an input interface, as self documenting code, no? (if required that is)... more elegant

[zoechi]

I'm not convinced. Would [requiredInput]="null" fulfill the contract or not?

[born2net]

it would not.
[requiredInput]="true" or even [requiredInput]="SomeType" would...
or
@RequiredInput: Foo

[zoechi]

This would require flow analysis.

What if you have

[requiredInput]="someUninitializedProperty"

[born2net]

At least you can give a runtime error specific to the requirement during run time

[DzmitryShylovich]

Use @input on a setter and throw error yourself.

[lazarljubenovic]

IMO The only value that wouldn't fulfill the contract would be undefined.

But zoechi's example with null has the point: with something like @Input() @Required(), what does it mean that it's "required"? Just listing it in the template doesn't really help you all that much if you don't know what is required. Not listing something is the same as giving it undefined (or leaving it default).

It would make more sense if we could specify a function which validates the input, but that's possible only in runtime and is pretty much the same as validating it yourself.

If the issue is making your code more pretty, here's a possible workaround: you can implement your own decorator for this:

@Ensure(input => input > 10)
@Input()
public foo: number = 20;

This would create a setter for foo and throw if the passed function is not satisfied for the new value given to foo.

[zoechi]

Not sure what you mean with your last comment.

Aren't runtime errors the exceptions we discussed above? The presence of binding doesn't provide much information (for example null case as mentioned).

The next step would be declarative support for validators to check if the provided values match the requirements like:

@Input()
@Required()
@NotNull()
@MinLength(5)
@MaxLength(15)
someInput:string;

That requires the Angular2 team to respond if they want to provide something like that.

It also would need to solve the question when these values need to be provided.
When ngOnInit() is called or is it enough to provide them later, when a response of a server call became available, ...

This is IMHO quite easy to solve with custom code (throw 'You didn't do xxx but it's required') instead of some declarative approach.

[born2net]

o.k. tx for the input (no pun intended :)