Open Bartheyrman22 opened 1 week ago
I'm sorry, are you really talking about 1000 items in the list ?
Yes, tom-select advertises for being performant with 15.000 items. And for me personally, it is working fast for +/-1000 items. So no need for Ajax in this case (maybe not best practice). And if ux-autocomplete hangs on 1000 items it will probably be slow on 100 items?
And wondering, is there a way to make the MutationObserver more specific? For instance not triggering on Select-events? Another possibility is that the controller does some DOM changes that triggers the MutationObserver. All in this specific case (multiple/grouped). I saw some select-items disapppearing and added on other places, operations that don't occur when using the tom-select without the ux-controller.
Wow i did not know this was even doable :)
Do you feel to investigate this problem and suggest maybe a PR ?
Would love to, I'm only not 100% sure about the responsibilities of the MutationObserver. Do you have a small description of what it's supposed to do? This way I can test if all functionality is still working after a fix. I understand so far, that it checks for changes on the select-list and updates the tom-select-widget accordingly?
The ux-autocomplete mutation-observer is triggered when selecting items from the list. I believe only in multiple/grouped-choice mode. This hangs the page/browser when using enough items in the list. (+1000) By removing the mutation-observer, the widget becomes fast again.