0

Webcomponents use the shadow dom for style encapsulation . From the specifications you know that the styles inside the shadow root are locally scoped . What would be the effect on memory when you instantiate the same webcomponent multiple times ? Ex : You instantiate your custom button webcomponent 10 times .

Example

#Shadow-root
<style>
.outer {
  border: 2px solid brown;
  border-radius: 1em;
  background: red;
  font-size: 20pt;
  width: 12em;
  height: 7em;
  text-align: center;
}
.inner {
  color: white;
  font-family: sans-serif;
  padding: 0.5em;
}
.name {
  color: black;
  background: white;
  font-family: "Marker Felt", cursive;
  font-size: 45pt;
  padding-top: 0.2em;
}
</style>
<div/>

I might import the style.css or place something inline like above . There might be props to the custom element and based on the props the component behaviour keeps changing . Now if such a component gets repeated 50 times , then I would see the inline style also getting repeated 50 times . Does browsers do any optimization between instances ?

If the style is getting duplicated then isnt the css in js a better solution than shadow dom for encapsulation ? You could really optimize the css thats used in the entire dom with a decent jss generation plugin.

charan
  • 71
  • 6
  • Possible duplicate of [Share style across web components "of the same type"](https://stackoverflow.com/questions/42645363/share-style-across-web-components-of-the-same-type) – Supersharp Jul 23 '18 at 09:42

1 Answers1

0

If the style is getting duplicated then isnt the css in js a better solution than shadow dom for encapsulation ?

Wherever the CSS is placed globally or inside a Shadow DOM, it is always applied to all the DOM tree (and therefore duplicated to all the DOM elements matched).

What would be the effect on memory when you instantiate the same webcomponent multiple times ?

So I doubt using a unique global CSS tag will optimize anything. At least not for 50 occurences. Maybe yes with hundreds.

Also it depends on the browser implementation and thereforce will be very vendor-dependant, and may vary in time as new browser version are released.

=> I can only recommend you to test/benchmark your specific use case.

Supersharp
  • 29,002
  • 9
  • 92
  • 134
  • In the example i gave , the style tag content is 20 lines... which is for a relatively smaller component . But some components can carry styles of 100 to 500 lines. Ex : some ant-design input component styles.. Isnt this not bloating the dom ? I dont need to do this with unique classnames in css-in-js. – charan Jul 23 '18 at 16:45
  • Maybe but it's not specific to custom element and shadow dom. It's the case with every html element : the CSS style is applied to every elements. In order to optimize the style rendering you'd better concentrate on CSS style good practice, that is: choose some rules that will generate a minimum of recalcultations. It's not a question of size but quality :-/ – Supersharp Jul 23 '18 at 17:24
  • May be i have to be more specific . css in js 1 input control style is 500 lines of css . 10 input controls style = 500 lines . But with inline styling in shadow dom 1 input control =500 lines . 10 input controls = 10 * 500 = 5000 lines . Is there no impact on the browser performance ? Doesnt the browser need to understand 4950 lines more in case of webcomponents with shadow dom & inline styling ? – charan Jul 24 '18 at 12:22
  • What is CPU-consuming is not to parse 5000 lines of CSS code but to recalculate badly designed complex CSS layout, with or without Shadow DOM. – Supersharp Jul 24 '18 at 22:16
  • I think the point here is not about good css or bad css . My question is about the technology , the overhead a technical approach is adding . – charan Jul 25 '18 at 05:36
  • I've already answered: the overhead depends on the specific hardware, the browser-specific implementation, the developer-specific coding, the specific use case so it must be tested in real conditions. There's no general answer to such a question. – Supersharp Jul 25 '18 at 08:50