My use case is that the filtered list becomes unresponsive in a large (or even not so large file) when the full scd file's ExtRefs are shown in a single filtered list in the oscd-subscriber-later-binding plugin (in the subscriber view)
This helps for moderate sized lists but not adequately for large lists but is probably worth doing any way. It is very likely that we should choose a number slightly lower than 500 ms (250? 300? 350? 400?)
This is for a file which has about 3620 ExtRef elements. Quite a few of these are "empty" but many relays fully expose their maximum capability in the quantity of ExtRefs they export.
To improve performance with a large number of list items, I suggest using a debounce on the
@input
for the search box, something like:My use case is that the filtered list becomes unresponsive in a large (or even not so large file) when the full scd file's ExtRefs are shown in a single filtered list in the oscd-subscriber-later-binding plugin (in the subscriber view)
I found this article on debouncing/throttling helpful: https://blog.webdevsimplified.com/2022-03/debounce-vs-throttle/
This helps for moderate sized lists but not adequately for large lists but is probably worth doing any way. It is very likely that we should choose a number slightly lower than 500 ms (250? 300? 350? 400?)
This is for a file which has about 3620 ExtRef elements. Quite a few of these are "empty" but many relays fully expose their maximum capability in the quantity of ExtRefs they export.
IEC61850_GOOSE_2-section.scd.zip
I think this is a realistic scenario - we use schemes like this in production now.