React Hooks misleading benchmark ?

I’ve been testing neverland against React, as it’s fully inspired by its hooks concept. However, if you remove the key={item.id} assignment from this row, to make it non-keyed, the benchmark runs fine only because the removed rows are decreasing, but never increasing.

If you just drop that key and you build-prod and try to remove twice the same row, or row 2 then row 4, you’ll have the whole benchmark/browser stuck forever because the logic is incapable to deal with such scenario.

Accordingly, since I believe React with hooks doesn’t require mandatory keyed transforms, and apologies if it does as I wasn’t aware of it, the current benchmark is misleading, as the same code, or similar up to the keyed point, cannot be used in non-keyed scenarios.

I am not sure this means React with hooks result should be invalidated, as it actually works well when keyed rows are used, but I think I’ve found a glitch in this benchmark suite, as the removal of rows should rather be both for the previous row, but also for the row after, to bail out all frameworks incapable of dealing with real-world scenarios, instead of having facilitated only the “drop previous row” one, which is currently the case.

Please let me know if you’d like me to file a PR that change the current row removal benchmark, or penalize keyed tests that wouldn’t work once non-keyed, or even ignore this issue, as considered not relevant for the current results.

Thank you.

[ryansolid]

@ryansolid if you look closer, hyperHTML is there and scores 100% from years ago … so yes, I’m aware of that, and all my libraries would easily deal with that test-case 😉

Of course your work has been very influential on the Web Component side of things. I was just mentioning that many Virtual DOM libraries weren’t as good as they were today. Your libraries have always been at the forefront for Web Components in my mind and I have a lot of respect for your work. Which is why I was so curious about your thoughts on these nagging details of keyed/non-keyed.

[WebReflection]

@krausest I still think having the change in the remove bench would help revealing other gotchas:

await testTextContains(driver, `//tbody/tr[6]/td[1]`, '11');
await clickElementByXPath(driver, `//tbody/tr[6]/td[3]/a/span[1]`);
await testTextContains(driver, `//tbody/tr[6]/td[1]`, '12');

it adds not much time to execute that test, but it helps understanding implementations