Skip to content

fix(icon): prevent parsing the same icon set multiple times #9635

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

Merged
merged 1 commit into from
Jan 29, 2018

Conversation

jelbourn
Copy link
Member

@jelbourn jelbourn commented Jan 27, 2018

This fixes an issue where requests for icons in a particular set made while that set is being fetched result in the set being parsed into an SVGElement multiple times. It occured because, while the same pending http request was used for each icon, each icon added their own map onto that request, will every map
resulting in a (potentially expensive) parse. This change sets the cached icon earlier and checks it later.

@jelbourn jelbourn added P1 Impacts a large percentage of users; if a workaround exists it is partial or overly painful pr: needs review G This is is related to a Google internal issue labels Jan 27, 2018
@jelbourn jelbourn requested review from crisbeto and mmalerba January 27, 2018 00:51
@googlebot googlebot added the cla: yes PR author has agreed to Google's Contributor License Agreement label Jan 27, 2018
This fixes an issue where requests for icons in a particular set made
while that set is being fetched result in the set being parsed into an
SVGElement multiple times. It occured because, while the same pending http
request was used for each icon, each icon added their own `map` onto
that request, will every `map` resulting in a (potentially expensive) parse. This change sets the cached icon earlier and checks it later.
@mmalerba mmalerba added pr: lgtm action: merge The PR is ready for merge by the caretaker and removed pr: needs review labels Jan 27, 2018
Copy link
Member

@crisbeto crisbeto left a comment

Choose a reason for hiding this comment

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

LGTM, left a couple of nits.

// Normally we avoid spying on private methods like this, but the parsing is a private
// implementation detail that should not be exposed to the public API. This test, though,
// is important enough to warrant the brittle-ness that results.
spyOn(iconRegistry, '_svgElementFromString' as any).and.callThrough();
Copy link
Member

Choose a reason for hiding this comment

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

Rather than spying on a private method, you should be able to assert the same by reproviding the DOCUMENT token and spying on createElement.

Copy link
Member Author

Choose a reason for hiding this comment

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

I think long-term the "right" thing to do is to break SVG parsing into its own utility and then use a mock for MatIconRegistry, which would make sense to do as part of #5188

// It is possible that the icon set was parsed and cached by an earlier request, so parsing
// only needs to occur if the cache is yet unset.
if (!config.svgElement) {
config.svgElement = this._svgElementFromString(svgText);
Copy link
Member

Choose a reason for hiding this comment

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

This one could be shortened to config.svgElement = config.svgElement || this._svgElementFromString(svgText).

@jelbourn jelbourn merged commit e6e4c3c into angular:master Jan 29, 2018
@jelbourn jelbourn added the target: patch This PR is targeted for the next patch release label Jan 29, 2018
@jelbourn jelbourn deleted the icon-set-caching branch April 2, 2018 22:32
@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 8, 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 cla: yes PR author has agreed to Google's Contributor License Agreement G This is is related to a Google internal issue P1 Impacts a large percentage of users; if a workaround exists it is partial or overly painful target: patch This PR is targeted for the next patch release
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants