allow using shadow dom for table row element

[nweldev]

Allow using Shadow Dom for table row.

closes #753

Requires:

• to use an autonomous custom element named benchmark-row with
  a shadowRoot containing one HTMLTableRowElement
• to add set useRowShadowRoot to true in "js-framework-benchmark"
  in the integration's package.json

After running some benchmarks, I'm pretty sure this doesn't change results when not using useRowShadowRoot. Yet,
results for "partial update", "swap rows" & "remove row" seems wrong with shadow dom. I didn't find why, but to be fair I didn't spend a long time on this (for now, I only care about first time rendering). Any idea would be very welcome.

Here, vanillajs-custom-el is pretty much the same thing as vanillajs-shadow, except it doesn't use a shadow dom, and shadow includes some styles (which leads to worse performances).

See #754 for the actual implementations (https://github.com/krausest/js-framework-benchmark/pull/754/files#diff-413524b880ced413f398ac03ee5043f1 & https://github.com/krausest/js-framework-benchmark/pull/754/files#diff-603af2a878606c27fdf7d1827bcf7564).

[nweldev]

@krausest for now, I have to focus on other parts of my own project, for which the issues related to "partial update", "swap rows" & "remove row" aren't a priority. Do you have any idea what could cause those? If not, this PR will take me a very long time to finish, sorry for that.

[krausest]

@noelmace I haven't see that behaviour yet. Here's a first screenshot of the Vanilla PR (not including today's commit) with this PR applied.

Partial update looks fine to me.

[ryansolid]

@krausest Partial Update might be fine but I think from what he's saying he expects this to be the slowest of the batch. Basically similar to custom-el-keyed but slower across the board. So the fact that it has the fastest partial update even if down to variance is suspect.

I'm trying to think how having isolated shadow roots would affect measuring in a keyed benchmark. Especially for Swap and Remove row which have the operations on the outside. Partial update and selection would be in the root I think. Not sure it's a bit unexpected.

[krausest]

Ok - I'm starting to understand. I thought the high duration of partial update for all but vanillajs-shadowed was the problem.
I think the issue is that vanillajs-shadow-keyed isn't using the right style (at least on my machine):

[ryansolid]

That makes sense depending on how the styles are included. They make a majority of the time in all the mentioned benchmarks especially in remove row/and swap row (part of the reason non-keyed) is faster. Partial update also touches enough rows for this to matter more (unlike select). I guess we need to double check if the style rules are applying properly. Something like bootstrap won't work. We can't just apply the hierarchical/inherited styles. We'd need to make styles that are row specific and specialized for the shadow root. Which means loading different assets or at least inlining different rules.

[nweldev]

Would you like me to send another PR with the vanillajs-shadow implementation?

I could add a preload style link in the shadow DOM too, just to be sure. It only works on Chrome, but this could be a good solution to start testing this.

[nweldev]

He expects this to be the slowest of the batch. Basically similar to custom-el-keyed but slower across the board. So the fact that it has the fastest partial update even if down to variance is suspect.

This is true for "pure" rendering (like "create row") but not for "partial update", "remove row" and especially not "swap rows". I expected those to be more efficient (because of the styles), but not that much (x2 or event x3 faster than vanillajs).

Seeing #764 (comment), there seem to be some issues with "partial update" on my side. @krausest any idea what may have caused that?

[krausest]

Would you like me to send another PR with the vanillajs-shadow implementation?

I could add a preload style link in the shadow DOM too, just to be sure. It only works on Chrome, but this could be a good solution to start testing this.

Please do! I‘ll take a look at it.

[krausest]

@noelmace I don't have a good idea. What OS are you running on? I had the feeling that the slowdown on windows is much more drastic than on Linux/OSX, but I haven't really looked into it.
But that doesn't explain the difference between vanillajs-shadow and the others on your machine.
Did you see it before PR #764 or was it introduced with that PR?

[nweldev]

I'm using Linux (Manjaro) on an old computer (i7-3630QM CPU @ 2.40GHz with 8G of RAM).
vanillajs-shadow can't be tested without #764 and other results were generated before it. I'll need to rerun all bench to be sure, but those needs a long time on my only computer.