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
Conversation
@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 |
May be |
Will do. |
a3c54fe
to
167a5c2
Compare
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) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
use format
There was a problem hiding this comment.
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)); |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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.
167a5c2
to
6806d73
Compare
6806d73
to
cde675a
Compare
Thanks for the update. LGTM. |
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. |
Please check if the PR fulfills these requirements
What kind of change does this PR introduce? (check one with "x")
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")
If this PR contains a breaking change, please describe the impact and migration path for existing applications: ...
Other information: