-
-
Notifications
You must be signed in to change notification settings - Fork 4.1k
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
css: false
does not disable CSS injection for customElement builds
#4124
Comments
That's my understanding of the current situation, yes. See point 2 of Rich's post: https://dev.to/richharris/why-i-don-t-use-web-components-2cia Given that, I don't think it makes much sense to let the CSS be extracted - what would you do with it? |
Hmm, it feels to me like these tradeoffs could be workable. I don't really care about FOUC; because I think the reality with runtime-heavy frameworks like React and Angular is that you get a FOUC waiting for the render step anyway; which is why you need to use SSR and client-side hydration. What I'm saying is- you should deal with FOUC by separating your CSS and JS in your build process and rendering all of it statically into the Given that the style assignments are done in the constructor of So where previously a class MyComponent extends SvelteElement {
// ...
}
customElements.define("my-component", MyComponent);
export default MyComponent; I would have it instead output this: class MyComponentUnstyled extends SvelteElement {
// ...
}
export function createStyledElement(styleString) {
return class styled extends MyComponentUnstyled {
constructor(options) {
this.shadowRoot.innerHTML = `<style>${styleString}</style>`;
super();
}
}
}
const MyComponent = createStyledElement("...");
customElements.define("my-component", MyComponent);
export default MyComponent; If
This gives the developer all necessary flexibility to create new component sub-classes with individual, runtime-defined styles. There might be complications depending on when the constructor of an |
I've made a pass at this, based on what I believe should be the expected behaviour. But it feels strange in a way that bears talking about— confusion RE the
What does this mean regarding the expectations of a Regardless, I think I'd like to see the addition of runtime injection for customElements.define("someCustomStyledComponent", createStyledElement(someCustomCSSString)); See also #4117 (comment) where I am keeping an informal requirements list & test cases for a related issue building on this. |
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
This issue has been closed as it was previously marked as stale and saw no subsequent activity. |
In pursuit of #4117 I'm trying to generate both Svelte and WebComponent versions of my build in a way that retains separation between the style and script bundle. If I use
css: false
with the default compilation mode this does exactly what I want-add_css
is no longer injected into the output component code.However, when using
customElement: true
the component still ends up with styles being injected via assignment tothis.shadowRoot.innerHTML
. So I think there is a possible bug with related questions:customElement
versions of components ifcss: false
is specified?customElement
build output that allows such dynamic injection of styles?Running Svelte
3.16.4
; Ubuntu 18.04; Firefox 71. Not using Webpack or Rollup (doing low-level compiler integrations).The text was updated successfully, but these errors were encountered: