perf(core): set encapsulation to None for empty component styles
#57130
Conversation
0b941f9 to
a488571
Compare
|
And of course I made a typo in the commit message - should be |
None for empty component stylesNone for empty component styles
|
Also, the |
|
@JoostK I agree it might break some apps, but as far as I understand it only in the case where someone explicitly assumes the existence of these attributes? They should never be referenced by styles managed by the framework since it only gets triggered if those styles are absent. I'm perfectly fine with this being considered a breaking change out of caution, let me know if I need to update the PR description or update the commit with BREAKING CHANGES Re: scope - makes sense, do I need to amend the commit message and do a force-push or is changing the PR title sufficient to correct this? |
|
We assume this might break some unit tests that rely on those attributes. We'll first test this change against all the test internaly a google. From this point, we'll assess if we make this a breaking change or not. We'll let you know the process if we require some changes ! |
Only the actual commit message matters, the PR title is irrelevant. |
|
This came up green across Google, so we can go ahead with this. Thanks for your contribution! |
|
(the cleanup label is for the commit message change) |
a488571 to
9cad12d
Compare
|
Updated the commit message from |
None for empty component stylesNone for empty component styles
|
Just in case anyone outside Google experiences test failures after updating and finds this PR: If the failing test expects a component to have You might need to update the test's expectations or add some dummy styles to the tested component (example) |
9cad12d to
9ae8c9b
Compare
Make it so that encapsulation for empty styles, styles containing only whitespace and comments, etc. is handled the same way as with no styles at all. Components without styles already have view encapsulation set to `None` to avoid generating unnecessary attributes for style scoping, like `_ngcontent-ng-c1` (angular#27175) If the component has an empty external styles file instead, the compiler would generate a component definition without the `styles` field, but still using the default encapsulation. This can result in runtime overhead if the developer forgets to delete the empty styles file generated automatically for new components by Angular CLI. Closes angular#16602
9ae8c9b to
be07825
Compare
|
I'm removing merge ready label as there seem to be a few failures in the TGP. |
|
Caretaker note: TGP is "green" after deflaking some targets. |
|
This PR was merged into the repository by commit 97fb86d. The changes were merged into the following branches: main |
|
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. |
Make it so that encapsulation for empty styles, styles containing only whitespace and comments, etc. is handled the same way as with no styles at all.
Components without styles already have view encapsulation set to
Noneto avoid generating unnecessary attributes for style scoping, like_ngcontent-ng-c1(#27175)If the component has an empty external styles file instead, the compiler would generate a component definition without the
stylesfield, but still using the default encapsulation. This can result in runtime overhead if the developer forgets to delete the empty styles file generated automatically for new components by Angular CLI.Closes #16602
PR Checklist
Please check if your PR fulfills the following requirements:
PR Type
What kind of change does this PR introduce?
What is the current behavior?
Issue Number: #16602
Example code to see the difference ("standard" metadata omitted for brevity)"
The first component still uses the default encapsulation, even though neither of them have any styles in the final
ɵcmpdefinitionWhat is the new behavior?
Both components now end up with
encapsulationset toNone(2) in the final bundleThe same should be true for any component whose styles contain only whitespace or comments, as those get stripped during the build -- at least with source maps turned off.
Does this PR introduce a breaking change?
If a component has no styles then nothing should be referencing the
_nghost-/_ngcontent-attributes, at least from Angular's side. An app could in theory break if it relies in some other way on those attributes being present, but since their names are semi-random, I'd consider that unlikely.Other information
The case of an empty style file being leftover after generation is fairly common, at least in my experience. This is sometimes intentional, component styles get added and removed quite frequently when developing a new feature, so constantly adding and deleting the file would be pretty annoying, especially with merge conflicts.