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.

Sign up for GitHub

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

Jump to bottom

RFC: Shadow DOM migration mode #83

Open
wants to merge 9 commits into
base: master
Choose a base branch
from
Open

RFC: Shadow DOM migration mode #83

Changes from 1 commit
Commits
Show all changes
9 commits
Select commit Hold shift + click to select a range
b18e778
RFC: Shadow DOM migration mode
nolanlawson Nov 14, 2023
b6d3e17
fix: update pr link
nolanlawson Nov 14, 2023
624b959
fix: specify SSR
nolanlawson Nov 17, 2023
8a00b3f
fix: tweak wording
nolanlawson Nov 20, 2023
7a57af6
fix: tweak wording
nolanlawson Nov 20, 2023
f3e2212
fix: tweak wording
nolanlawson Nov 20, 2023
ef7906c
fix: remove technical details
nolanlawson Dec 4, 2023
99155da
fix: typo
nolanlawson Dec 4, 2023
abc6ef3
fix: add notes about forced mode
nolanlawson Jan 30, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
1 change: 1 addition & 0 deletions text/0000-synthetic-shadow-migrate.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -151,3 +151,4 @@ We could also potentially leverage [lwc-codemod](https://github.com/salesforce/l

- Do any non-stylesheet behaviors of synthetic shadow DOM need to be emulated?
- How should component-level API versioning apply to this, if at all? E.g., should the "forced" opt-in be done gradually, only for newer API versions?
- Should we have a separate rollout strategy for environments where we want to forcibly remove synthetic shadow DOM? For example, a global "forced" migrate mode could simply assume that any component without `static shadowSupportMode = 'native'` should run in migrate mode. This would allow for removing synthetic shadow from the page entirely.
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 sympathetic with this approach. I do think that "migrate" is the wrong term, and "forced" is also the wrong term. I think this paragraph will have us to reflect on the nature of this feature better.

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'm fine with whatever name we want. People seem to really like "synthetic synthetic shadow."

Copy link
Contributor

Choose a reason for hiding this comment

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

looking at the core functionality of this rather than looking at the problem it solves, this is about styles... specifically global styles being propagated into the shadow. Based on that, something like 'native-with-global-styles' seems very odd and long... perhaps something like 'style-able'. Another alternatives is to never leak this value to the client, basically, it is not observable from code, in which case we don't need a name for it. The question is, when would someone manually use that value in their code?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Another alternatives is to never leak this value to the client

Yes, this is the question of opt-in vs opt-out. This PR assumes opt-in since the context is assumed to be a B2B app like LEX.

The question is, when would someone manually use that value in their code?

Per this PR, the answer is "when the component author wants to migrate to native shadow DOM but cannot due to breaking changes due to a reliance on synthetic shadow DOM style leakage."