feat(input): support types date, time, datetime-local, month, week #5864

benlesh · 2014-01-17T18:57:16Z

partially closes #757

Merged from PR #5256

benlesh · 2014-01-17T18:59:23Z

I'm combining my other related pull requests: #5543, #5541, #5423, #5422, #5256

This is because the others were all branched on top of one another and maintaining them was getting unwieldy.

Also this is in preparation to "DRY" the code up, since these 5 controls share most of their logic.

benlesh · 2014-01-17T19:02:49Z

Side note, it wasn't good that I was slamming Travis every time I had to update a deeper branch, because I'd also have to rebase the other branches "above" it and push them to Github. It was a mess. This should be cleaner.

kbudde · 2014-01-17T19:07:58Z

+1

benlesh · 2014-01-18T04:58:07Z

Added a second commit to reduce the code size quite a bit: benlesh@952e08a

I know that generally the Angular team would like single commits for a pull request, but given the size and scope of this PR, I'm leaving them both intact so they can be reviewed independently.

I'll fix them up when it's necessary.

Narretz · 2014-01-19T00:31:23Z

It's actually okay to have multiple commits in your pull for larger changes, as long as they are sound units, and it adds to understanding them. They can be squashed before merging them. It was Igor or Brian who wrote this a few weeks ago in another pull.

tbosch · 2014-02-04T21:52:28Z

src/ng/directive/input.js

+     *
+     * @description
+     * HTML5 or text input with date validation and transformation. In browsers that do not yet support
+     * the HTML5 date input, a text element will be used. The text must be entered in a valid ISO-8601


Please add "In that case, the text must be entered ..." so it's clear that this is only the fallback case.

Same for input widgets below

tbosch · 2014-02-04T21:55:37Z

src/ng/directive/input.js

+     * @description
+     * HTML5 or text input with date validation and transformation. In browsers that do not yet support
+     * the HTML5 date input, a text element will be used. The text must be entered in a valid ISO-8601
+     * date format (yyyy-MM-dd), for example: `2009-01-06`. Will also accept a valid ISO date or Date object


Could you change this (doc and implementation) so that the model always needs to be a JS Date object?
If we allow a string initially, then the data type of the variable in the model changes when the user first enters a value. By this, js code that uses that model property always needs to check which case it is, and this will most probably lead to bugs...

I thought about this, but I left it as it is now because it's extremely common that I'm actually putting a date string I've recieved from an AJAX call into the model. It's very nice to have for the workflow:

Get some JSON data via Ajax containing dates

The dates in the JSON are going to be strings initially.

They're generally displayed directly into forms.

When they're sent back to the server, they're automatically sent back as strings.

Another precedent for this functionality is the date filter, which allows for either Date object or string dates to be input, and it will still format the date properly.

Thoughts?

I understand your point.
But this is not the right place to convert Strings from the backend to
Dates. A http interceptor or something similar would be more appropriate.

On Tue, Feb 4, 2014 at 2:08 PM, Ben Lesh notifications@github.com wrote:

In src/ng/directive/input.js:

@@ -89,7 +94,345 @@ var inputType = {
*/
'text': textInputType,

/**

\* @ngdoc inputType

\* @name ng.directive:input.date

*

\* @description

\* HTML5 or text input with date validation and transformation. In browsers that do not yet support

\* the HTML5 date input, a text element will be used. The text must be entered in a valid ISO-8601

\* date format (yyyy-MM-dd), for example: `2009-01-06`. Will also accept a valid ISO date or Date object

I thought about this, but I left it as it is now because it's extremely
common that I'm actually putting a date string I've recieved from an AJAX
call into the model. It's very nice to have for the workflow:

Get some JSON data via Ajax containing dates

—
Reply to this email directly or view it on GitHubhttps://github.com//pull/5864/files#r9441282
.

I considered the same thing. However, this seems like the easiest place to do it, because this is a point where you have a string that was just identified, probably for the first time, as being a Date. At any point prior to this in it's life cycle, there just really isn't an efficient way of identifying it, without explicitly mapping conversions, or inefficiently traversing the object looking for dates to convert.

In order for Angular to be buttery-smooth with Dates and these HTML5 controls, some sort of seamless conversion is nearly a must. Would you like me to put in a PR or two for some options regarding converting strings to dates?

I actually have a service I made to convert a string to a date, taking into account $locale.

Looking at it again, the documentation is outdated and inaccurate. It looks like I removed the functionality that was scrubbing strings into dates when coming in from the model some time ago...

Still.. my offer to produce a few spikes for a date converter, or some date tools stands.

... and... looking again, it seems to allow it even though I'm not explicitly changing it... I'll investigate that further and implement tests around making sure that only Date objects are accepted from the model.

Yes,
a PR would be nice. However, please don't leave it in the directive.

On Fri, Feb 7, 2014 at 8:56 AM, Ben Lesh notifications@github.com wrote:

In src/ng/directive/input.js:

@@ -89,7 +94,345 @@ var inputType = {
*/
'text': textInputType,

/**

\* @ngdoc inputType

\* @name ng.directive:input.date

*

\* @description

\* HTML5 or text input with date validation and transformation. In browsers that do not yet support

\* the HTML5 date input, a text element will be used. The text must be entered in a valid ISO-8601

\* date format (yyyy-MM-dd), for example: `2009-01-06`. Will also accept a valid ISO date or Date object

I considered the same thing. However, this seems like the easiest place
to do it though, because this is a point, where you have a string that was
just identified, for the first time, as being a Date. At any point prior to
this in it's life cycle, there just really isn't an efficient way of
identifying it, without explicitly mapping conversions, or inefficiently
traversing the object looking for dates to convert.

In order for Angular to be buttery-smooth with Dates and these HTML5
controls, some sort of seamless conversion is nearly a must. Would you like
me to put in a PR or two for some options regarding converting strings to
dates?

I actually have a service I made to convert a string to a date, taking
into account $locale.

—
Reply to this email directly or view it on GitHubhttps://github.com//pull/5864/files#r9546086
.

tbosch · 2014-02-04T22:41:09Z

This is pretty good!
I left some comments mainly regarding code style / small refactorings.

I really look forward to having these new input types in master soon!
Please ping me when you made the changes.

petebacondarwin · 2014-02-28T19:32:09Z

src/ng/directive/input.js

+     'HH:mm'),
+
+   /**
+    * @ngdoc inputType


@ngdoc input

petebacondarwin · 2014-02-28T20:14:06Z

So I guess that browsers just default to a text type if they don't recognise the type attribute?

benlesh · 2014-02-28T20:20:38Z

Correct. In fact, if you were to write a polyfill, that's precisely what you check

var input = document.createElement('input');
input.type = 'banana';
if(input.type === 'text') {
    console.log('browser does not have HTML7 banana input!');
}

petebacondarwin · 2014-02-28T20:52:25Z

There is quite a bit of change to be made in the ngdoc comments due to the new Dgeni generated documentation. I did a rebase locally and there were a number of conflicts to fix up due to this. Sorry.
But running locally, all the unit tests are passing. Just waiting for the protractor tests...

benlesh · 2014-02-28T20:57:00Z

Sorry for what? Haha. These things happen. Things get updated, other things need refactored. That's what that DEL is for. Shouldn't be terrible for me to rebase and make the changes. I'll try to make time over the weekend.

petebacondarwin · 2014-02-28T21:09:17Z

Build is passing locally for me and once I modified one of the examples, it works fine in the docs. I would say that after a rebase, this is ready to go.

petebacondarwin · 2014-02-28T21:18:25Z

Here's my rebased branch if you want to use it as a starting point: petebacondarwin/angular.js@angular:master...petebacondarwin:date-inputs

benlesh · 2014-02-28T21:38:54Z

Shall I just add it as an upstream of my own branch?

benlesh · 2014-03-03T05:39:26Z

@petebacondarwin and @tbosch ... I've rebased the branch, and I've updated all of the e2e tests in the documentation to use protractor. It's a good thing I did too, because I think there are going to be some confused developers when they go to use web driver to "sendKeys" to an HTML5 input like one of these (or even one like color), because it doesn't really work and now the example tests show the workaround.

partially closes angular#757

tbosch · 2014-03-06T20:22:28Z

Thanks @Blesh! Keep up the good work!!

caitp · 2014-03-06T20:26:11Z

👍 \o/ *confetti*

benlesh · 2014-03-06T21:04:29Z

Cool! Whenever I get done collaberating with @juliemr around angular/protractor#562, I'll create a new issue and PR with updated e2e tests in the docs that leverage the new ptor extension.

On older browser that don't support the new HTML5 inputs and display a text input instead, the user is required to enter the data in the corresponding ISO format. The value in `ng-model` will always be a date. E2e tests contain a workaround to a bug in webdriver, see angular/protractor#562. Also adds weeks as format to the `dateFilter`. Related to angular#757. Closes angular#5864.

This was referenced Jan 17, 2014

Add support for <input type="time"/> #5543

Closed

Add support for <input type="month"/> #5541

Closed

Add support for <input type="week"/> #5423

Closed

Added support for <input type="datetime-local"/> #5422

Closed

tbosch reviewed Feb 4, 2014
View reviewed changes

tbosch mentioned this pull request Feb 4, 2014

Add support for <input type="date"/> #5256

Closed

tbosch reviewed Feb 4, 2014
View reviewed changes

tbosch added this to the 1.3.x milestone Feb 4, 2014

tbosch self-assigned this Feb 4, 2014

tbosch added complexity: medium labels Feb 4, 2014

petebacondarwin reviewed Feb 28, 2014
View reviewed changes

src/ng/directive/input.js

'HH:mm'),

/**

* @ngdoc inputType

Copy link

Contributor

petebacondarwin Feb 28, 2014

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@ngdoc input

This was referenced Mar 1, 2014

clear() or sendKeys('') not working on input types: date, time, datetime-local, month, or week angular/protractor#562

Open

angular.element.val() and jquery.val() should call $setViewValue() when necessary #6523

Closed

feat(input): support types date, time, datetime-local, month, week

cad8e0e

partially closes angular#757

btford modified the milestones: 1.3.0-beta.1, 1.3.x Mar 4, 2014

tbosch closed this in 46bd6dc Mar 6, 2014

estekhin mentioned this pull request Aug 4, 2014

1.3.0 input[date] model is a Date object in local time zone instead of UTC #8447

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

feat(input): support types date, time, datetime-local, month, week #5864

feat(input): support types date, time, datetime-local, month, week #5864

benlesh commented Jan 17, 2014

benlesh commented Jan 17, 2014

benlesh commented Jan 17, 2014

kbudde commented Jan 17, 2014

benlesh commented Jan 18, 2014

Narretz commented Jan 19, 2014

tbosch Feb 4, 2014

tbosch Feb 4, 2014

tbosch Feb 4, 2014

benlesh Feb 4, 2014

tbosch Feb 4, 2014

benlesh Feb 7, 2014

benlesh Feb 7, 2014

benlesh Feb 7, 2014

tbosch Feb 7, 2014

tbosch commented Feb 4, 2014

petebacondarwin Feb 28, 2014

petebacondarwin commented Feb 28, 2014

benlesh commented Feb 28, 2014

petebacondarwin commented Feb 28, 2014

benlesh commented Feb 28, 2014

petebacondarwin commented Feb 28, 2014

petebacondarwin commented Feb 28, 2014

benlesh commented Feb 28, 2014

benlesh commented Mar 3, 2014

tbosch commented Mar 6, 2014

caitp commented Mar 6, 2014

benlesh commented Mar 6, 2014

feat(input): support types date, time, datetime-local, month, week #5864

feat(input): support types date, time, datetime-local, month, week #5864

Conversation

benlesh commented Jan 17, 2014

benlesh commented Jan 17, 2014

benlesh commented Jan 17, 2014

kbudde commented Jan 17, 2014

benlesh commented Jan 18, 2014

Narretz commented Jan 19, 2014

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

tbosch commented Feb 4, 2014

Choose a reason for hiding this comment

petebacondarwin commented Feb 28, 2014

benlesh commented Feb 28, 2014

petebacondarwin commented Feb 28, 2014

benlesh commented Feb 28, 2014

petebacondarwin commented Feb 28, 2014

petebacondarwin commented Feb 28, 2014

benlesh commented Feb 28, 2014

benlesh commented Mar 3, 2014

tbosch commented Mar 6, 2014

caitp commented Mar 6, 2014

benlesh commented Mar 6, 2014