(datepicker): Ability to avoid having strings as model values

[AbakumovAlexandr]

Description:

As docs say:

If the entered input value is invalid, the form model will contain the entered text.

So, as an user types some date into Datepicker, we have a sequence of model values consisting from null, some intermediarystrings, and finally, some Date object.

Suppose, we have an underlying model which doesn't expect anything except null/Date (or whatever type our custom NgbDateAdapter turns NgbDateStruct into) and suppose you don't have the control over that model's code, since it's from some kind of framework like BreezeJS.

When it gets a string where Date or null is expected, it could simply fail.

Or it could try to coerce that string into a Date somehow. If Date.parse() is used for that, the latter leads to a completely confusing results looking like broken browser auto-complete (in Chrome, immediately after typing a "1", it gets parsed into 01/01/2001; try Date.parse("1"), but not in Edge\FF). Moreover, due to inconsistency in Date.parse() across browsers, it creates varying behaviors which is a total mess.

I'm not sure even why writing strings to the model which most likely expects a certain kind of a date type or null is the viable option enabled by default. With the strict TS typing, it requires you to have ALL Datepicker model properties to be of this ugly and confusing union type:

public datepickerModel: NgbDateStruct (or whatever date type you're using) | string | null;

Which apparently complicates your life significantly, since you're now forced to always check if the actual value is not a string.

Version of Angular, ng-bootstrap, and Bootstrap:

ng-bootstrap: 3.1.0

[maxokorokov]

I think I agree that for the datepicker it should never be a string, should be something similar to: https://stackblitz.com/edit/angular-abqhfr?file=app/datepicker-overview-example.html

• we should make model null for invalid parsing
• we should report a parsing error

It's definitely not a fix, but a breaking change for me.

@pkozlowski-opensource, any specific reasons why it shouldn't be done this way ?