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
feat: light DOM scoped styles #2332
Conversation
3ab8663
to
c03a9a8
Compare
1240317
to
b43799b
Compare
Assuming nothing changes in the RFC, this PR is ready for review. |
849118e
to
3b5d3a4
Compare
packages/@lwc/style-compiler/src/__tests__/fixtures/import-in-scoped/actual.css
Show resolved
Hide resolved
@@ -97,11 +106,13 @@ enum LWCDOMMode { | |||
|
|||
export function fallbackElmHook(elm: Element, vnode: VElement) { |
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.
We might want to change the name of this function to something more representative. I was originally called this way to encapsulate the fallback logic when the LWC engine is not running with native shadow DOM.
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.
Hm, maybe setStyleTokensAndObserve
? That seems to be what it's doing, for both synthetic shadow and light DOM scoped styles.
Or I could move the light DOM style scoping to a new hook.
20ec8a2
to
0e6a63b
Compare
aeb36a7
to
6ef52fa
Compare
6ef52fa
to
bddc9c5
Compare
bddc9c5
to
7627d08
Compare
This PR is ready for a second look. The changes are:
|
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.
Added a couple of nitpicks otherwise the code looks good.
@@ -155,5 +156,5 @@ function normalizeOptions(options: TransformOptions): NormalizedTransformOptions | |||
stylesheetConfig, | |||
outputConfig, | |||
experimentalDynamicComponent, | |||
}; | |||
} as NormalizedTransformOptions; |
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.
The NormalizedTransformOptions
interface should be updated to avoid the type guard.
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.
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.
Actually, I can't seem to get this to work. TypeScript keeps throwing errors during the build, and I don't understand the problem. Let's address it in a future PR.
return ''; | ||
} else if (scopeToken) { | ||
// load the file ourselves without the query param | ||
return fs.readFileSync(filename, 'utf-8'); |
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.
It is strange that we have to load scoped styles manually from within the plugin while the rest of the files aren't. I understand why this is needed here. However, I am wondering rollup provides a better way to handle this?
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.
Disclaimer I haven't tried this approach. But could we, for example, parse the query string in the resolveId
, shelve the query string key/value in the file meta
. This would avoid having to add custom logic in the load
. The meta
can then be retrieved in the transform
hook to invoke the compiler correctly.
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.
This sounds plausible to me; let's handle in another PR? It would need some experimentation.
Co-authored-by: Pierre-Marie Dartus <p.dartus@salesforce.com>
Co-authored-by: Pierre-Marie Dartus <p.dartus@salesforce.com>
Co-authored-by: Pierre-Marie Dartus <p.dartus@salesforce.com>
@nolanlawson I am seeing an issue when trying to run a LWR/LWC site. I need to remove in order to have my LWR/LWC code to function correctly. Is there anything I need to change in my lwr.config.json to make it function correctly:
|
Details
Rough implementation of this RFC. Adds a
*.scoped.css
file for light DOM components that results in CSS that is scoped to that component.Does this PR introduce breaking changes?
No, it does not introduce breaking changes.
GUS work item
W-8844642