Components: Browser hangs when DatePicker's Input is bound to a function that returns Date translated from a string

[another-guy]

Bug:

input mdInput's ngModel bound to a function that returns a Date object "hangs" the page.

What is the expected behavior?

The datepicker should display the date that represents the original date string.

What is the current behavior?

The browser page "hangs" (stack overflow likely).

What are the steps to reproduce?

https://plnkr.co/edit/icHhtOd4493dnc41uaY7?p=preview

If the component code is changed to the following, the browser page hangs:

private _myDate = '2016/12/25';
get myDate(): Date { return new Date(this._myDate); }
set myDate(newValue: Date) { /* irrelevant*/ }

What is the use-case or motivation for changing an existing behavior?

The model object has the dates in string format (ISO 8601 in real code), which should be the first class citizen just like Date.

Which versions of Angular, Material, OS, TypeScript, browsers are affected?

Angular-material beta10

[willshowell]

Tracking for use of ISO 8601 strings: https://github.com/angular/material2/issues/6265#issuecomment-326436693

Read here about setting up a date adapter to parse whatever you want in the mean time: https://github.com/angular/material2/issues/6773

Is it a requirement that your form model strictly uses strings? Why not just convert it to a date object once and pass that around instead?

[another-guy]

Tracking for use of ISO 8601 strings: #6265 (comment)

@willshowell Subscribed, Thanks a ton!

Read here about setting up a date adapter to parse whatever you want in the mean time: #6773

Implementing the DateAdapter that works with ISO8601 string as a single representation is cumbersome, but I am trying to do that now...

Is it a requirement that your form model strictly uses strings? Why not just convert it to a date object once and pass that around instead?

Yes, it is an [internal technical] requirement. It is VERY painful to deal with Date in our JS code (that includes in-/out- translations on client-server communication). On our project we decided to use ISO8601 string as a single date, time, or date/time representation everywhere across the code base.

In JS we only use ephemeral Date objects when it comes to date/time arithmetic. As soon as the calculations are done, we translate the result into ISO8601 string again and lock it there.

I can not claim that most of the projects are following the same approach, but I believe that many do. Keeping in mind how painful dealing with Date can be in JS, back-end, databases, and across the board, I personally think that ISO8601 should be used as a base for the alternative _native DateAdapter_.

[another-guy]

@willshowell I am actually following this blog post. https://blog.angular.io/taking-advantage-of-the-angular-material-datepicker-237e80fa14b3

[another-guy]

As a work in progress I got this (which is dependent on date-fns): Sorry for tons of console.xxx() -- still debugging this messy beast.

Please, see code in Gist: https://gist.github.com/another-guy/adc2d9d731af7693fdbfab21b1e227a9#file-iso8601datestringadapter-ts

[another-guy]

Tracking issue: #6265

[angular-automatic-lock-bot[bot]]

This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.

Read more about our automatic conversation locking policy.

_{_This action has been performed automatically by a bot._}