tomek-he-him
commented
8 years ago Hi, thanks a lot for your interest in this lib! I didn’t really have the time and motivation to spread the word about it – hence the low popularity.
As for your point,
the amount of tests in bare-select is very minimal
Have you looked in the test/ directory or at the CI results? We do our best to develop test-driven – so every piece of functionality is unit tested. There are well over 100 tests to cover every type of scenario.
Naturally, you rather mean benchmarks than unit tests. I haven’t added any of these, because that wasn’t relevant for our use-case back when I developed this thing. I’ve got three thoughts though:
- Generally speaking, this is just a slim wrapper around native DOM elements. All we do is listen to some events and route them to the right plugins. It’s the browser itself who takes care of folding and unfolding, animations, marking the selected item and all these things. So the performance should be virtually as good as that of raw DOM.
- The only thing we actually do is clone the contents of the selected
<li>to stick it in the uppermost<label>. As long as you don’t have a ridiculously deep DOM tree inside (and that’s very unlikely), it’s also a very fast thing. - We don’t bundle any stylesheet with
<bare-select>. The overall performance depends mostly on the user’s own stylesheet. We can’t benchmark that.
We haven’t noticed any performance problems in the production apps we ship. If we do, we’ll surely do a benchmark and in-depth profiling. But otherwise, feel free to PR!
This seems like a great library, and I would love to migrate away from select2 and replace it with bare-select, since select2's way of managing its dropdown items is to append the DOM elements to the <body> element.
However, the amount of tests in bare-select is very minimal (as is the number of watchers, stars and forks on github), and there is especially no performance tests. Ergo, I am creating this placeholder for adding performance testing.
I am open to discussions on best practices for measuring performance of these kinds of controls, as I have never attempted it before. So, this issue also serves as a stomping ground for ideas on how we should go about performance testing. Below are some basic ideas:
Test Dimensions
Number of dropdowns on an HTML page
1, 50, 100, 500, 5000
Number of items in a dropdown
10, 50, 100, 500, 5000
Number of sub-elements in each li option and li label elements
1, 25, 50
To maximize maintenance of these test cases, I propose pair-wise testing so that we test: 1 dropdown, with 10 item, with 1 sub-element 1 dropdown, with 10 items, with 1 sub-element 50 dropdowns, with 50 items, with 1 sub-element etc...