Enterprise: O controle suspenso multisseleção apresenta baixo desempenho no IE11 quando a lista suspensa contém +500 opções

Os resultados do nosso teste para isso parecem muito melhores do que esses números para mim.
http://master-enterprise.demo.design.infor.com/components/dropdown/test-2000-items.html

Talvez haja um problema específico com a seleção múltipla. Eles têm o mesmo código, mas alguns caminhos diferentes.

No código de teste final, você tinha um? Ou muitos drop downs?

@tmcconechy , para meus testes, tenho 5 controles multisseleção na página. Quando mudo esses controles para um menu suspenso (não multisseleção), noto uma melhoria significativa no desempenho. Este problema parece específico dos controles multisseleção.

Discutindo esse assunto, um pouco curioso sobre o caso de uso real? Que tipo de escolha multisseleção o usuário está fazendo?

@picitelli é a melhor pessoa para conversar.
Pelo que entendi, a lista precisa ser construída sempre que o menu suspenso for ativado e pode haver até cerca de 2.000 itens, dependendo da função do usuário. Eles precisam recarregar o menu suspenso em alguns pontos, mas não podem se comunicar com o plug-in do Mongoose.
Não tenho certeza de que tipo de opções de seleção múltipla estão sendo feitas.
Eu li muito sobre o IE11 ter um desempenho ruim ao adicionar itens ao DOM em geral e incluir alguns links abaixo.
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

Definitivamente, o IE é lento no DOM, mas eu queria saber o caso de uso real em que o usuário vê 500 coisas e precisa escolher quais. Parece que no máximo 50 opções seria mais apropriado para uma IU de decisão / seleção.

Provavelmente podemos torná-lo mais rápido, mas imaginando se o caso de uso seria melhor atendido por um componente diferente.

Com certeza seria melhor atendido por um componente diferente, mas o cliente pede é para usar o dropdown. Se quisermos voltar e dizer, este não é o componente certo e você terá problemas no IE11 ... talvez atualizar para o Edge? Suponho que poderíamos oferecer a sugestão.

@tmcconechy , para nosso aplicativo, temos 4 controles suspensos de seleção múltipla que um usuário pode acessar para filtrar os resultados em uma página de listagem de pedidos. A quantidade de opções que aparecem nesses menus suspensos é baseada na seleção do usuário e também nas permissões (função) que um usuário recebe. Um usuário regular estará limitado a ver apenas uma pequena gama de opções. Depois que eles fazem as seleções, temos uma chamada de API que preenche mais opções em um controle suspenso secundário usado para filtragem adicional. (Esses menus suspensos se comunicam entre si.)

Um usuário com permissões totais de administrador verá todas as opções no controle suspenso. No momento, o total de opções é de 1969. Esse número pode crescer de acordo com o que o cliente deseja utilizar.

Um usuário pode ver apenas 2-50 opções dentro do controle, mas se receberem permissões adicionais, a quantidade de opções que eles têm pode se expandir até 1969. Não queremos oferecer outro controle (por exemplo, pesquisa de produto) que adiciona um etapa adicional para que eles interajam e executem seu processo de filtragem quando o controle de seleção múltipla for a melhor opção, especialmente quando a maioria dos usuários verá um número menor de opções.

É frustrante lidar com o IE11 e sei que o desempenho não é ideal quando há tantas opções sob controle. Esse mesmo controle, usado sem a configuração "múltiplo" e como apenas uma lista suspensa de seleção, não tem as mesmas preocupações de desempenho no IE11 quando há cerca de 2.000 opções. Somente como multisseleção existe esse grande problema de desempenho.

Eu também gostaria que fosse tão simples quanto dizer a eles para atualizarem seus navegadores, mas este aplicativo é para os clientes clientes, que estão predominantemente no IE11.

@tmcconechy @EdwardCoyle
Tenho trabalhado com diversas soluções para otimizar este código para o IE e não encontrei nenhuma solução que, uma vez implementada, aumente o desempenho do IE11. Minha recomendação neste ponto é recuar e sugerir um componente diferente se eles quiserem um melhor desempenho. A partir de agora, o menu suspenso e a multisseleção funcionam muito bem com até 500 itens. 2000, conforme solicitado nesta edição, parece-me excessivo para tal componente.
Fico feliz em receber qualquer conselho ou discussão além deste tópico de comentários.

@picitelli se pedimos que suportemos o IE11 nessas condições, a solução não é simples. Nosso componente suspenso precisaria de uma revisão muito séria, pois nunca foi projetado com esse tipo de carga em mente.

@davidcarlsonberg @clepore @nickwynja @tmcconechy devemos conversar sobre este. Eu tenho algumas idéias sobre como lidar com o desempenho, mas essas idéias caem no território de "refatoração".

Eu pensei que havia uma grande diferença entre o dropdown com 2000 e multiselect com 2000. Você explorou a diferença na velocidade para um ganho mais imediato.

Eu estava olhando mais para a causa raiz da queda no desempenho. Posso investigar dropdown multiselect vs plain dropdown se quisermos alterar o escopo deste tíquete para ver o que pode ser ganho lá para uma vitória rápida.

Sim, definitivamente vale a pena dar uma olhada, eu estava baseando essa suposição neste comentário https://github.com/infor-design/enterprise/issues/843#issuecomment -424495956

Qualquer coisa pode ajudar, mesmo que seja um pouco "um pouco" mais rápido

Prosseguirei para determinar e melhorar a diferença entre o menu suspenso e a multisseleção.

Acho que @EdwardCoyle está correto ao dizer que precisaríamos reformular isso do zero, usando técnicas mais modernas para aumentar a eficiência. Não tenho certeza se vale a pena gastar mais de um dia neste @davidcarlsonberg .

@picitelli Continuaremos procurando opções para lidar com esse caso de ponta de desempenho.

Acho que a melhor opção para este caso é usar um indicador de ocupado :

Um indicador de ocupado notifica o usuário de que o sistema está processando uma solicitação e que ele deve aguardar o processamento dessa solicitação antes de continuar com a tarefa atual.

Aqui está um exemplo de como usá-lo em um campo:

• 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

A melhor experiência seria aguardar um segundo ou mais e exibir apenas o indicador de ocupado se a lista ainda não tiver aparecido.

Após exame no Chrome recente no macOS, a diferença no dropdown vs multiselect response() tempo de execução. Observe as unidades.
lista suspensa: 512,14 ms
multisseleção: 1,02 s

@tmcconechy @davidcarlsonberg @EdwardCoyle @clepore Agradeço a todos que estão analisando este problema. Especialmente @davidcarlsonberg , obrigado por dedicar seu tempo a isso. Há quase 2 semanas tentamos otimizar para o IE11 e não encontramos nada além de becos sem saída. Concordo com a avaliação de que esse controle não foi feito para lidar com essas muitas opções e outro controle seria mais adequado.

@nickwynja , apresentará sua recomendação de indicador de atividade com design e verá o que eles dizem.

Obrigado novamente a todos!

Encerrando este problema, pois não há nenhum teste de controle de qualidade envolvido. Por favor, veja os comentários para mais informações.