Repository navigation
fix(DatePipe): parse string input ourselves to avoid inconsistency between browsers - #13895
DzmitryShylovich wants to merge 2 commits into
Conversation
|
Sweet, now I don't need moment to fix ONLY Safari |
There was a problem hiding this comment.
@DzmitryShylovich do you have any source reference for this RegExp?
There was a problem hiding this comment.
There was a problem hiding this comment.
This is super-light on tests.... I would expect that a change like this comes with much, more tests for both valid and invalid cases.
As a comment for the existing test: if we expect sth to not throw we should assert what should be the exact result, not just the fact that it doesn't throw.
There was a problem hiding this comment.
As mentioned above, my biggest grip with this PR is that we don't have enough tests... As the very minimum we should:
- add tests that demonstrate what happens for invalid inputs (ex.:
2015-06-15Taaaaa - what is the output for "valid" cases - as of today this PR just check that we don't throw but I could make those tests pass by deleting all the code from the pipe...
There was a problem hiding this comment.
What happens if the input is a string but not a valid ISO string? If I'm reading the code correctly it will still try to create Date object, right? But what is the point if we know that the string is invalid?
There was a problem hiding this comment.
will still try to create Date object, right?
yeap. afaik there's no universal pattern for a iso 8601 date. So even if a string doesn't match our regex it can still be a valid date in some browsers. Sort of a fallback. But we can probably remove
} else {
date = new Date(value);
}
There was a problem hiding this comment.
Yes, I think that we should decide if we parse date ourselves or still mess with the Date object. If I'm reading things correctly ng1 is taking over parsing completely: https://github.com/angular/angular.js/blob/dea8ae9af0e59b6727f3f732ea1fae8bb4368b0a/src/ng/filter/filters.js#L613-L623
So even if a string doesn't match our regex it can still be a valid date in some browsers.
Do you have examples? Or is it sth that you suspect?
|
@DzmitryShylovich I'm on a fence with this one - I'm not super-keen on duplicating parsing logic... let me think about this one some more. In any case it would need much more tests if we go down this path. |
|
@pkozlowski-opensource can we get this labeled for merge or close? |
There was a problem hiding this comment.
As mentioned above, my biggest grip with this PR is that we don't have enough tests... As the very minimum we should:
- add tests that demonstrate what happens for invalid inputs (ex.:
2015-06-15Taaaaa - what is the output for "valid" cases - as of today this PR just check that we don't throw but I could make those tests pass by deleting all the code from the pipe...
|
@DzmitryShylovich so my biggest issue with this PR is that we don't have enough tests and as such we can't guarantee that we are not introducing breaking changes... Also i18n-related pipes are pending rewrite so I'm not keen on merging anything that is not critical. If you could more tests to this PR (especially ones exploring corner cases) we could merge it but I fell uneasy getting it in as-is. |
|
@pkozlowski-opensource ready for review
ok I added parsing at the end, where we already know that string is not a valid date in browser, so we won't introduce a breaking change accidentally. |
|
This one is good to go if you ask me. |
… browser (angular#13895) Closes angular#12334 Closes angular#13874 PR Close angular#13895
… browser (angular#13895) Closes angular#12334 Closes angular#13874 PR Close angular#13895
… browser (angular#13895) Closes angular#12334 Closes angular#13874 PR Close angular#13895
|
This issue has been automatically locked due to inactivity. Read more about our automatic conversation locking policy. This action has been performed automatically by a bot. |
Closes #12334 and #13874
Implementation from ng1