Quick question:
Does the team developing the framework have any plans on replacing knockout.js with something else?
Apparently 5.x still uses it. If abandoning it is considered, is there a roadmap / calendar about this?
It’s more like a dormant idea at this point. We now have “fixed” the main issues we had with knockout (or rather worked around them), so it’s not a priority. Definitely not for version 5. The main ways to avoid knockout issues in specific situations is using dotvvm.state (setState, …) and JsComponent. If you have some specific need where knockout is getting in the way, let us know, maybe there already exists a reasonably easy solution
1 Like
I believe that the lag from this issue I face: [bp:MultiSelect] flooding the client-side console with warnings & errors + lag
is due to knockout getting in the way.
What do you think?
In this case, the problem is crappy implementation of the component: the list of all values is in the DOM for each component — the popup list is only hidden with CSS, and it’s being updates with each observable update…
Then, do you have any suggestion, maybe, on how to get rid of the lag? It is a front-end issue for sure.
Maybe build your own Multiselect or individual components that aren’t working like you want. I’ve been using Dotvvm controls and building custom controls instead of using bootstrap controls.
Just an opinion, probably not the best idea.
1 Like
Unfortunately, MultiSelect is quite hard to replace… I filed a PR to kindof fix the problem for MultiSelect specifically, but it seems that all BP are keeping all of their popups in the DOM even when not touched by the user 
1 Like
For some 15+ huge lists of 3000+ items, lag of over 30secs when loading all together or when closing the popup(modal) holding the entire form.
I’m thinking of creating a custom alternative based on MultiSelect but I don’t have priority on that right now so I don’t know when I’ll be able to come with some feedback on this aspect.
Too bad, MultiSelect is very nice in terms of functionality and how it looks and the fact that it is part of the control pack, but has this performance issue for cases like this one, where the web form is quite heavy with data sets. But yes, looking forward to your fix, exyi, I appreciate that you addressed the control’s drawback.
Why not lazy loading the data on scroll when multiselect is open if the problem is the initial loading time? Or the problem is more about the popups in DOM ?
Interesting idea, @wolfstudiodev.
For certain, I have to say that “grind-to-a-halt” type of lag happens also when interacting with the large lists (3000+ items) by selecting and removing them.
LE: also, the user needs to be able to readily filter the entire item list by typing characters in the MultiSelect (that nice filter-as-you-type feature it has). I suppose that this need contradicts the lazy(partial) loading approach but its just a hunch, I’m not sure if it would exclude it.
@exyi
Can you remind me, please, when the PR you mentioned would be publicly available in the Business Pack? …To try out the new MultiSelect.
If you decide to go for custom multiselect and wanna some help I can contribute in what I can. I like it cuz it’s a way to share opinions and learn with more people.
1 Like