Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fix(facade): cache original date format string #12764

Merged
merged 1 commit into from Dec 5, 2016

Conversation

awerlang
Copy link
Contributor

@awerlang awerlang commented Nov 8, 2016

Please check if the PR fulfills these requirements

What kind of change does this PR introduce? (check one with "x")

[X] Bugfix
[ ] Feature
[ ] Code style update (formatting, local variables)
[ ] Refactoring (no functional changes, no api changes)
[ ] Build related changes
[ ] CI related changes
[ ] Other... Please describe:

What is the current behavior? (You can also link to an open issue here)

There's a useless cache being maintained in the Intl facade for dates. Its purpose it's to avoid a possibly expensive RegExp operation. Unfortunately the expensive result was being cached in the wrong entry (null).

What is the new behavior?

Add to the correct cache entry.

Does this PR introduce a breaking change? (check one with "x")

[ ] Yes
[X] No

If this PR contains a breaking change, please describe the impact and migration path for existing applications: ...

Other information:

@pkozlowski-opensource pkozlowski-opensource added the area: common Issues related to APIs in the @angular/common package label Nov 8, 2016
@pkozlowski-opensource
Copy link
Member

@awerlang this looks good to me, generally speaking, well spotted. What makes me nervous, though, is that we don't seem to have any tests that would help us to catch this / similar issues in the future. Could you think of the way of testing this (ex. formatting with a given format and then trying to format with null one to get an unexpected format from the cache?).

@vicb
Copy link
Contributor

vicb commented Nov 8, 2016

May be const cacheKey = format TS will complain if the key gets modified ?

@awerlang
Copy link
Contributor Author

awerlang commented Nov 8, 2016

Could you think of the way of testing this (ex. formatting with a given format and then trying to format with null one to get an unexpected format from the cache?).

Will do.

@awerlang awerlang force-pushed the fix-dateparts-cache branch 3 times, most recently from a3c54fe to 167a5c2 Compare November 8, 2016 20:19
@awerlang
Copy link
Contributor Author

awerlang commented Nov 8, 2016

I decided to go with a spy. It's the only way we can detect the presence of a transparent cache.


while (format) {
match = DATE_FORMATS_SPLIT.exec(format);
while (pattern) {
Copy link
Contributor

Choose a reason for hiding this comment

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

use format

Copy link
Contributor Author

Choose a reason for hiding this comment

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

done

spyOn(Map.prototype, 'set').and.callThrough();
DateFormatter.format(date, locale, pattern);
expect(Map.prototype.get).toHaveBeenCalledWith(pattern);
expect(Map.prototype.set).toHaveBeenCalledWith(pattern, jasmine.any(Array));
Copy link
Contributor

Choose a reason for hiding this comment

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

I'm not sure if this test is valuable ?

  • It exposes impl details,
  • It doesn't really test the cache behavior.

@pkozlowski-opensource ?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I see your point. I can export a new DateFormatCache class instead of Map and use exclusively for this caching. WDYT?

Copy link
Contributor

Choose a reason for hiding this comment

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

I wouldn't mind if we remove this test

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Removed the test as requested. Let me know if there's anything blocking.

@vicb vicb added action: merge The PR is ready for merge by the caretaker pr_state: LGTM labels Dec 3, 2016
@vicb
Copy link
Contributor

vicb commented Dec 3, 2016

Thanks for the update. LGTM.

@alxhub alxhub merged commit a132287 into angular:master Dec 5, 2016
maxime-allex pushed a commit to Linkurious/angular that referenced this pull request Dec 6, 2016
maxime-allex pushed a commit to Linkurious/angular that referenced this pull request Dec 6, 2016
@angular-automatic-lock-bot
Copy link

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.

@angular-automatic-lock-bot angular-automatic-lock-bot bot locked and limited conversation to collaborators Sep 10, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
action: merge The PR is ready for merge by the caretaker area: common Issues related to APIs in the @angular/common package cla: yes
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants