regression: datepicker marked invalid if custom adapter is used, since 4.2.0

[jnizet]

Bug description:

When a custom adapter is set on a datepicker popup, the form control is marked invalid by the invalidDate validator.
My debugging showed that every time we pick a date, the calendar.isValid()method is called several times with the NgbDate, but ends up being called with the control value, which is not an NgbDate, but is the adapted value, which thus fails the validation.

Link to minimally-working StackBlitz that reproduces the issue:

https://stackblitz.com/edit/angular-c54t21?file=app%2Fdatepicker-adapter.html

This is just a trimmed down version of the "custom adapter" demo example. Select a date, and you'll see that it's always marked invalid.

Versions of Angular, ng-bootstrap and Bootstrap:

Angular: 7.x, 8.0

ng-bootstrap: 4.2.0

Bootstrap: 4.x

[jnizet]

Note that it only works by accident when no adapter is present, because the value of the control is an NgbDateStruct, which happens to have the same properties as an NgbDate.

[SimonWilliams-STL]

We are experiencing this issue using NgbDateNativeAdapter.

[eran10]

+1

[jnizet]

Also note that the other datepicker validators are broken too, but in the other way: they return null (no error) when the control value is not a date struct. So the minDate and maxDate validators consider any value as valid as soon as a date adapter is used.

Can we revert the commit 509bba3 and make a fix release, until this is figured out?

Some design is necessary before exposing the validators, IMHO.

They should at least use the adapter to get back an NgbDateStruct, then transform it to a NgbDate before checking the validity of the NgbDate with the calendar. But even with this additional argument, I wonder if it's a good idea to transform the NgbDate to some model value and then transform it back to an NgbDate to validate the value. Maybe the initial problem solved by this commit should be resolved in another way.

[maxokorokov]

Thanks for comments and sorry about this!
Unfortunately, I don't have the time to investigate this properly at the moment, so quickest fix at the moment would be to revert the commit with 4.2.1 as @jnizet suggested.

[jnizet]

Thanks for the quick fix and release @maxokorokov ❤️