Clarity: clrDate in Android / iOS browsers does not bind

Created on 12 Aug 2018  路  6Comments  路  Source: vmware/clarity

Select one ... (check one with "x")

[x] bug
[ ] feature request
[ ] enhancement

Expected behavior

When the user selects a date using the native browser widget the date is bound to the object in the component.

Actual behavior

Date object is undefined.

Reproduction of behavior

Requires using iOS / Android

https://clarity-light-theme-v012-wb9dcb.stackblitz.io




Environment details

  • Angular version: 6.0.9

  • Clarity version: 0.12.5

  • OS and version:

  • Browser: [all Mobile browsers]

Dev mobile bug

Most helpful comment

My debugging notes.

The native date controls from both iOS 11 and Android 8.1 browsers when using the date
input field are emitted as yyyy-mm-dd format. The null / undefined comes from
DateIOService. The date fields are extracted based on the regular expression
match (yyyy,mm,dd) but in validateAndGetDate it ends up with MIDDLE_ENDIAN and passes
(dd,yyyy,mm) where the argument list is expecting (yyyy,mm,dd) for validation which fails.

MIDDLE_ENDIAN is selected based on both the constructer of DateIOService and
initializeLocaleDisplayFormat. LocaleHelperService reports that our date localeDateFormat
is M/d/yy which qualifies for MIDDLE_ENDIAN_REGEX.

All 6 comments

I just tried on iOS, I can confirm something 馃悹 is happening. But debugging is going to be pretty painful, and until we do I have no idea how to estimate that bug.

My debugging notes.

The native date controls from both iOS 11 and Android 8.1 browsers when using the date
input field are emitted as yyyy-mm-dd format. The null / undefined comes from
DateIOService. The date fields are extracted based on the regular expression
match (yyyy,mm,dd) but in validateAndGetDate it ends up with MIDDLE_ENDIAN and passes
(dd,yyyy,mm) where the argument list is expecting (yyyy,mm,dd) for validation which fails.

MIDDLE_ENDIAN is selected based on both the constructer of DateIOService and
initializeLocaleDisplayFormat. LocaleHelperService reports that our date localeDateFormat
is M/d/yy which qualifies for MIDDLE_ENDIAN_REGEX.

This is still an issue in v13.1-patch.1

Using two way databinding with devices that force the native picker returns null, as described by @kelvix.

Using FormControls however, returns the locale string representation of the date, even with native datepickers.

The is an issue for cases requiring ISO time. It is problematic because the locale output from the FormControl option has to be cast to ISO, which means figuring out the locale in your component first, and writing additional code to cast to the correct format.

In addition to handling native datepickers. Please consider adding an optional input to override the locale.

Oh right, #3159. Fixed this. Thanks for reminding us. 馃憤

Hi there 馃憢, this is an automated message. To help Clarity keep track of discussions, we automatically lock closed issues after 14 days. Please look for another open issue or open a new issue with updated details and reference this one as necessary.

Was this page helpful?
0 / 5 - 0 ratings