Enterprise: Multiselect dropdown control has poor performance in IE11 when dropdown list contains +500 options

The resukts on our test for this seem a lot better than those numbers to me.
http://master-enterprise.demo.design.infor.com/components/dropdown/test-2000-items.html

Pehaps there is an issue with multi select specifically. They have the same code but a few different paths.

In the end test code did you have one? Or many drop downs?

@tmcconechy, for my testing I have 5 multiselect controls on the page. When I change those controls to a dropdown (non-multiselect), I notice a significant improvement to the performance. This issue seems specific to the multiselect controls.

Discussing this issue, a bit curious about the actual use case? What kind of multiselect choices is the user making?

@picitelli is the best person to talk to.
From my understanding the list needs to build each time the dropdown is engaged and there can be anywhere up to around 2000 items depending on the user role. They need to reload the dropdown at points but cannot communicate with the plugin from Mongoose.
Not sure what kind of multiselect choices are being made.
I've read a lot about IE11 having poor performance adding items to the DOM in general and will include some links below.
https://developer.microsoft.com/en-us/microsoft-edge/platform/issues/4561410/
https://stackoverflow.com/questions/43003579/internet-explorer-11-very-slow-appending-elements-to-dom
https://stackoverflow.com/questions/24913564/appending-large-groups-of-elements-in-ie11-enormously-slow

Definitely IE is slow on the DOM but I was wondering the actual use case where the user is shown 500 things and has to pick which ones. Seems like maybe max 50 choices would be more appropriate for a decision/selection UI.

We can probably make it faster, but wondering if the use case would better be served by a different component.

It would be for sure better served by a different component, but the client ask is to use the dropdown. Whether we want to go back and say, this is not the right component and you are going to run into issues in IE11...maybe upgrade to Edge? I suppose we could offer the suggestion.

@tmcconechy, for our application, we have 4 multi-select dropdown controls that a user can access to filter results on an orders listing page. The amount of options that appear within these dropdowns are based on a user selection and also permissions (role) that a user is granted. A regular user will be limited to only see a small range of options. Once they make selections, we have an API call that populates more options in a secondary dropdown control used for additional filtering. (These dropdowns communicate with each other.)

A user with full admin permissions will see all options within the dropdown control. At the moment, the total amount of options is 1969. That number can grow, based on what the client wants to use.

A user might only see 2-50 options within the control, but if they are granted additional permissions, the amount of options they have can expand up to 1969. We don't want to offer another control (e.g. product lookup) that adds an additional step for them to interact with and perform their filtering process when the multi-select control is best option, especially when majority of users will see smaller number of options.

IE11 is frustrating to deal with, and I know performance is not optimal when there are so many options within the control. This same control, used without the "multiple" setting, and as just a single selection dropdown doesn't have the same performance concerns in IE11 when there are ~2000 options. Only as a multiselect is there this big performance issue.

I also wish it was as simple as telling them to upgrade their browser but this application is for the clients customers, which are predominately on IE11.

@tmcconechy @EdwardCoyle
I've been working with different solutions to optimize this code for IE and haven't come across any solution which, once implemented, increases the performance in IE11. My recommendation at this point is to push back and suggest a different component if they would like better performance. As of right now, the dropdown and multiselect both perform very well with up to 500 items. 2000 as is requested in this issue would seem to me to be excessive for such a component.
Happy to receive any advice or discuss apart from this comment thread.

@picitelli if the ask is for us to support IE11 under those conditions, the solution isn't straightforward. Our Dropdown component would need a pretty serious overhaul, as it was never designed with that type of load in mind.

@davidcarlsonberg @clepore @nickwynja @tmcconechy we should chat about this one. I've got some ideas on addressing the performance but those ideas land in "refactoring" territory.

I thought that there was a major difference between dropdown with 2000 and multiselect with 2000. Did you explore the difference in speed there for a more immediate gain.

I was looking more at the root cause of the decrease in performance. I can investigate dropdown multiselect vs plain dropdown if we want to change the scope of this ticket to see what can be gained there for a quick win.

Yes, its definitely worth a look i was basing this assumption on this comment https://github.com/infor-design/enterprise/issues/843#issuecomment-424495956

Anything might help even if its just a "bit" faster

I'll proceed on determining and improving the difference between dropdown and multiselect.

I think @EdwardCoyle is correct in that we'd need to overhaul this from the ground up using more modern techniques for efficiency. I'm not sure if its worth spending more than a day on this @davidcarlsonberg .

@picitelli We'll keep looking at options to address this performance edge case.

I think the best option for this case is to use a busy indicator:

A busy indicator notifies the user that the system is processing a request, and that they must wait for that request to be processed before continuing with the current task.

Here's an example of using it in a field:

• https://design.infor.com/code/ids-enterprise/4.10.0/demo/busyindicator/example-inputs?font=source-sans
• https://github.com/infor-design/enterprise/blob/4.10.0/app/views/components/busyindicator/example-inputs.html

The best experience would be to wait for a second or so and only display the busy indicator if the list hasn't appeared yet.

Upon examination in recent Chrome on macOS the difference in dropdown vs multiselect response() execution time. Please note units.
dropdown: 512.14 ms
multiselect: 1.02 s

@tmcconechy @davidcarlsonberg @EdwardCoyle @clepore I appreciate everyone looking into this issue. Especially @davidcarlsonberg , thanks for spending your time on this. We have been trying for almost 2 weeks on our end to optimize for IE11 and ran into nothing but dead ends. I agree with the assessment that this control was not meant to handle these many options and another control would be better suited.

@nickwynja, will take your busy indicator recommendation up with design and see what they say.

Thanks again all!

Closing this issue as there is no QA testing involved. Please see comments for more info.