[bp:MultiSelect] flooding the client-side console with warnings & errors + lag

Hi hi,

I am dealing with a page that is heavy in data sets and has a repeater of repeaters to build a suite of panels with multiple MultiSelect controls in each panel.

So, what goes wrong?


Crashing very verbosely on every adding or removal of the MultiSelect items. The more selected items it has, the more warnings appear and the control becomes very laggy. Population: circa 900+ items. The warnings still occur (both kinds) if I limit the list to 10 items - instead no lag this time.
LE: errors appear when I use this:
image

markup:

VM:


public List<ActivitiesPanelRow> Rows is what is bound to the child repeater DataSource.
Further, this entry class is part of the dictionary that is bound to the parent repeater DataSource:
image

BE.TipEntitateRetea is an enum.
The items are correctly selected on the server-side at PostBack.

What I’ve tried:

  • switching the order of DataSource & SelectedValues in the markup;
  • switching the names of ObjectivesDisplaySet_ & ObjectivesDisplaySetSelectedOptions between them;
  • both switches;
  • ItemValueBinding="{value: GUID}" instead of ItemKeyBinding. And adapting ObjectivesDisplaySetSelectedOptions to be List<Guid>;
  • Dictionary<int, ActivitiesPanelRepeaterEntry> ActivitiesPanels with int as key instead of as BE.TipEntitateRetea;
  • not using a Dictionary and binding a VM property directly to the child repeater as data source:
    image
    image
  • binding directly to MultiSelect with VM properties:
    image
    image
  • … taking the MultiSelect outside of the repeaters
  • taunting it with foul words;
  • doing the sample

If nothing works, any alternatives to bp:MultiSelect ?

Inside the child Repeater there are also <bp:DropDownList controls that I omitted for brevity. These also use a similar data structure (Dictionary<enum, class-with-nested-list) and are working well, nothing thrown in Console in browser.

I think that the performance issue with the bp:MultiSelect has something to do with the performance impact inherent to the knockout observables, at such volume of data (900 items).