Lit Web Components performance with attributes vs slots

[omkarvijf41]

We have developed a lot of web components for apps to reuse. Few components are simple and few of them are complex. Mostly Complex components apps pass big/nested JSON config as attributes as most of the logic is handled by the component itself. Eg: Nested nav or pagination and it's controls or table and it's sorting etc. Will there be any impact on the performance with this JSON attribute approach vs passing as a slot. How can we better improve lit web components performance.

[sorvell]

I appreciate the concise description, but we'll probably need a bit more information. Perhaps you could provide an example (a playground would be great) showing the technique you're using to configure the element via JSON. Please don't provide a complicated element, but a subset of one showing the general pattern(s) you're using would be helpful.

[omkarvijf41]

thanks for the quick response @sorvell. Here is the sample example of the table component. we recently ugraded to lit 3 and we are not yet using typescript for the components. I copied styles from another file to component styles just to check in the playground.
https://lit.dev/playground/#sample=examples%2Ffull-component&gist=dd8319897cf8e1eaca13962869f99f32

Please let us know if you need anything.

[omkarvijf41]

@sorvell Any luck with the above sample component.

[sorvell]

That's relatively complex, but since you asked about performance let's focus on that.

I would, however, recommend some refactoring. Consider making table rows and headers separate components and/or make the sticky version a separate component with shared logic.

For performance, using a JSON config like this and letting Lit render the resulting object is generally relatively fast. There are 2 main points to consider:

1. The main concern is updates. With a large monolithic config object like this, any update processes everything in the config. Lit will efficiently re-render only the changed values, but it's still possibly more work than is needed.
2. As with any list, the biggest impact on performance is the size of the list. And while it's good to focus on minimizing cost per row (like ensuring there's not just excessive DOM; I didn't see anything that stood out here), it's much more important to consider the number of rows. Depending on the performance demands, typically when you need to render more than a few hundred rows, you will want to consider techniques like pagination, lazy rendering, and virtualization.

If you did want to try using DOM instead of a JSON attribute, for a use case like this you'd likely want to create bespoke header and row components, and because of parsing issues with <table> you'd probably need to re-do the css at that point to use display: table, etc. It's not immediately clear if this, in and of itself, would have an overall positive impact on performance, but it would allow users more flexibility since they could embed whatever html they want.

[omkarvijf41]

Got it. Thank you very much @sorvell for the detailed explanation.

[vospascal]

Personaly i would set Json using methods and/or propertys never as attributes because they are stringify versions of the object you want to pass down. setting big strings as attributes aka is pretty limited in readablity in the dom and are probably slower. unlike in the past with IE i think you can set very big strings as attributes but the conversion is needed if you want to work with them as a object