Skip to content

refactor(list): use light-weight tokens for injecting parent lists #19568

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

Conversation

devversion
Copy link
Member

@devversion devversion commented Jun 8, 2020

Angular Material list items currently optionally inject a parent MatNavList
or MatList. This has the downside of retaining these tokens at runtime
because they are used for dependency injection as values.

We can improve this by using so-called light-weight tokens. These allow
us to continue injecting parent list or nav-lists, but without the risk of
retaining the MatList and MatNavList classes with their factories.

This was already the case before Angular v9 with View Engine, but
the problem became significantly worse with Ivy, where factories are now
directly attached to the classes (such as MatList or MatNavList).

Using light-weight tokens avoids this issue and gives us an additional
size improvement. Notably this won't be an improvement when an
application uses both the nav-list and standard MatList.

Related to angular/angular-cli#16866. More context on light-weight tokens in:
https://hackmd.io/@mhevery/SyqDjUlrU#.

Note: I'll be going through other components in the repo and send
similar changes (if applicable; and non-breaking).

@googlebot googlebot added the cla: yes PR author has agreed to Google's Contributor License Agreement label Jun 8, 2020
@devversion devversion force-pushed the refactor/size-improvement-light-weight-tokens branch 2 times, most recently from dc8e8eb to f185ca3 Compare June 8, 2020 19:36
@devversion devversion added P3 An issue that is relevant to core functions, but does not impede progress. Important, but not urgent target: patch This PR is targeted for the next patch release labels Jun 8, 2020
@devversion devversion marked this pull request as ready for review June 8, 2020 19:49
@devversion devversion requested review from crisbeto, jelbourn and a team as code owners June 8, 2020 19:49
@devversion devversion added the merge: preserve commits When the PR is merged, a rebase and merge should be performed label Jun 8, 2020
const expectedSize = Number(golden[testId]);
const absoluteSizeDiff = Math.abs(actualSize - expectedSize);

// Whether the size deviates by 1% from the expected.
Copy link
Member

Choose a reason for hiding this comment

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

We should document this at the top of the file where it says if the file size changes "by certain amount", to express these same values.

Alternatively, maybe these constants should be at the top of the file for easier discovery.

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 making this percentage based, what if it were just 1 kilobyte? Just because e.g. Overlay is big, doesn't mean we should necessarily tolerate larger size fluctuations in that package.

Copy link
Member Author

Choose a reason for hiding this comment

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

@jelbourn Exactly, but that's why we have an absolute byte change check too. The percentage is helpful when a change is smaller than the absolute threshold but is considered large in percentage of the expected size.

This matches the same conditions as in angular/angular. The absolute threshold is currently 500 bytes.

Copy link
Member Author

Choose a reason for hiding this comment

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

@josephperrott Moved it to the top-level as constants w/ comments. That should be better, agreed.

const expectedSize = Number(golden[testId]);
const absoluteSizeDiff = Math.abs(actualSize - expectedSize);

// Whether the size deviates by 1% from the expected.
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 making this percentage based, what if it were just 1 kilobyte? Just because e.g. Overlay is big, doesn't mean we should necessarily tolerate larger size fluctuations in that package.

Angular Material list items currently optionally inject a parent `MatNavList`
or `MatList`. This has the downside of retaining these tokens at runtime
because they are used for dependency injection as values.

We can improve this by using so-called light-weight tokens. These allow
us to continue injecting parent list or nav-lists, but without the
risk of retaining the `MatList` and `MatNavList` classes with their
factories.

This was already the case before Angular v9 with View Engine, but
the issue significance increases with Ivy where factories are now
directly attached to the classes (such as `MatList` or `MatNavList`).

Using light-weight tokens avoids this issue and gives us an additional
size improvement. Notably this won't be an improvement when an
application uses both the nav-list and standard `MatList`.

Related to https://github.com/angular/angular-cli/issues/16866. More
context on light-weight tokens in:
https://hackmd.io/@mhevery/SyqDjUlrU#.
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

Copy link
Member

@josephperrott josephperrott left a comment

Choose a reason for hiding this comment

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

LGTM, for dev-infra

Copy link
Member

@jelbourn jelbourn left a comment

Choose a reason for hiding this comment

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

LGTM

@devversion devversion added P2 The issue is important to a large percentage of users, with a workaround lgtm action: merge The PR is ready for merge by the caretaker and removed P3 An issue that is relevant to core functions, but does not impede progress. Important, but not urgent labels Jun 9, 2020
@andrewseguin andrewseguin added target: minor This PR is targeted for the next minor release and removed target: patch This PR is targeted for the next patch release labels Jun 11, 2020
@andrewseguin andrewseguin merged commit a290168 into angular:master Jun 11, 2020
@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 Jul 12, 2020
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 merge: preserve commits When the PR is merged, a rebase and merge should be performed P2 The issue is important to a large percentage of users, with a workaround target: minor This PR is targeted for the next minor release
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants