Enterprise: Le contrôle déroulant à sélection multiple a des performances médiocres dans IE11 lorsque la liste déroulante contient + 500 options

Les résultats de notre test me semblent bien meilleurs que ces chiffres.
http://master-enterprise.demo.design.infor.com/components/dropdown/test-2000-items.html

Peut-être qu'il y a un problème avec la sélection multiple spécifiquement. Ils ont le même code mais quelques chemins différents.

Au final, le code de test en aviez-vous un ? Ou plusieurs listes déroulantes ?

@tmcconechy , pour mes tests, j'ai 5 contrôles multiselect sur la page. Lorsque je change ces contrôles en une liste déroulante (non multisélection), je remarque une amélioration significative des performances. Ce problème semble spécifique aux champs multisélection.

Vous discutez de ce problème, vous êtes un peu curieux de connaître le cas d'utilisation réel ? Quel type de choix multisélection l'utilisateur fait-il ?

@picitelli est la meilleure personne à qui parler.
D'après ce que je comprends, la liste doit être construite à chaque fois que la liste déroulante est activée et il peut y avoir jusqu'à environ 2000 éléments en fonction du rôle de l'utilisateur. Ils doivent recharger la liste déroulante aux points mais ne peuvent pas communiquer avec le plugin de Mongoose.
Je ne sais pas quel type de choix multisélection est fait.
J'ai beaucoup lu sur les performances médiocres d'IE11 lors de l'ajout d'éléments au DOM en général et j'inclurai quelques liens ci-dessous.
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

IE est certainement lent sur le DOM, mais je me demandais le cas d'utilisation réel où l'utilisateur voit 500 choses et doit choisir lesquelles. Il semble que peut-être un maximum de 50 choix serait plus approprié pour une interface utilisateur de décision/sélection.

Nous pouvons probablement le rendre plus rapide, mais nous nous demandons si le cas d'utilisation serait mieux servi par un composant différent.

Il serait certainement mieux servi par un composant différent, mais la demande du client est d'utiliser la liste déroulante. Que nous voulions revenir en arrière et dire que ce n'est pas le bon composant et que vous allez rencontrer des problèmes dans IE11... peut-être une mise à niveau vers Edge ? Je suppose que nous pourrions offrir la suggestion.

@tmcconechy , pour notre application, nous avons 4 commandes déroulantes à sélection multiple auxquelles un utilisateur peut accéder pour filtrer les résultats sur une page de liste de commandes. Le nombre d'options qui apparaissent dans ces listes déroulantes est basé sur une sélection d'utilisateurs et également sur les autorisations (rôle) accordées à un utilisateur. Un utilisateur régulier sera limité à ne voir qu'une petite gamme d'options. Une fois les sélections effectuées, nous avons un appel d'API qui remplit plus d'options dans un contrôle déroulant secondaire utilisé pour un filtrage supplémentaire. (Ces listes déroulantes communiquent entre elles.)

Un utilisateur avec des autorisations d'administrateur complètes verra toutes les options dans le contrôle déroulant. À l'heure actuelle, le nombre total d'options est de 1969. Ce nombre peut augmenter en fonction de ce que le client souhaite utiliser.

Un utilisateur peut ne voir que 2 à 50 options dans le contrôle, mais si des autorisations supplémentaires lui sont accordées, le nombre d'options dont il dispose peut s'étendre jusqu'à 1969. Nous ne voulons pas offrir un autre contrôle (par exemple, recherche de produit) qui ajoute un étape supplémentaire pour qu'ils puissent interagir avec et effectuer leur processus de filtrage lorsque le contrôle à sélection multiple est la meilleure option, en particulier lorsque la majorité des utilisateurs verront un plus petit nombre d'options.

IE11 est frustrant à gérer, et je sais que les performances ne sont pas optimales lorsqu'il y a autant d'options sous le contrôle. Ce même contrôle, utilisé sans le paramètre "multiple", et en tant que simple liste déroulante de sélection n'a pas les mêmes problèmes de performances dans IE11 lorsqu'il y a environ 2000 options. Ce n'est qu'en tant que multisélection qu'il y a ce gros problème de performances.

J'aimerais aussi que ce soit aussi simple que de leur dire de mettre à jour leur navigateur, mais cette application est destinée aux clients clients, qui sont principalement sur IE11.

@tmcconechy @EdwardCoyle
J'ai travaillé avec différentes solutions pour optimiser ce code pour IE et je n'ai rencontré aucune solution qui, une fois implémentée, augmente les performances dans IE11. Ma recommandation à ce stade est de repousser et de suggérer un composant différent s'ils souhaitent de meilleures performances. Pour le moment, la liste déroulante et la sélection multiple fonctionnent très bien avec jusqu'à 500 éléments. 2000 comme demandé dans ce numéro me semble excessif pour un tel composant.
Heureux de recevoir des conseils ou de discuter en dehors de ce fil de commentaire.

@picitelli si la demande nous demande de prendre en charge IE11 dans ces conditions, la solution n'est pas simple. Notre composant Dropdown aurait besoin d'une refonte assez sérieuse, car il n'a jamais été conçu avec ce type de charge à l'esprit.

@davidcarlsonberg @clepore @nickwynja @tmcconechy nous devrions discuter de celui-ci. J'ai quelques idées sur la manière d'aborder la performance, mais ces idées atterrissent sur le territoire du "refactoring".

Je pensais qu'il y avait une différence majeure entre le dropdown avec 2000 et le multiselect avec 2000. Avez-vous exploré la différence de vitesse pour un gain plus immédiat.

Je cherchais davantage la cause première de la baisse des performances. Je peux étudier la liste déroulante multisélection par rapport à la liste déroulante simple si nous voulons modifier la portée de ce ticket pour voir ce qui peut y être gagné pour une victoire rapide.

Oui, ça vaut vraiment le coup d'oeil je basais cette hypothèse sur ce commentaire https://github.com/infor-design/enterprise/issues/843#issuecomment -424495956

Tout peut aider même si c'est juste un "peu" plus rapide

Je vais continuer à déterminer et à améliorer la différence entre la liste déroulante et la sélection multiple.

Je pense que @EdwardCoyle a raison en ce sens que nous aurions besoin de remanier cela de fond en @davidcarlsonberg .

@picitelli Nous continuerons à rechercher des options pour résoudre ce problème de performances.

Je pense que la meilleure option pour ce cas est d'utiliser un indicateur occupé :

Un indicateur d'occupation informe l'utilisateur que le système traite une demande et qu'il doit attendre que cette demande soit traitée avant de poursuivre la tâche en cours.

Voici un exemple d'utilisation dans un champ :

• 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

La meilleure expérience serait d'attendre environ une seconde et d'afficher l'indicateur occupé uniquement si la liste n'est pas encore apparue.

Après examen dans Chrome récent sur macOS, la différence entre le temps d'exécution de la liste déroulante et de la sélection multiple response() . Veuillez noter les unités.
liste déroulante : 512,14 ms
multisélection : 1,02 s

@tmcconechy @davidcarlsonberg @EdwardCoyle @clepore J'apprécie tous ceux qui se penchent sur ce problème. Surtout @davidcarlsonberg , merci d'avoir passé votre temps là-dessus. Nous avons essayé pendant près de 2 semaines de notre côté d'optimiser pour IE11 et nous n'avons rencontré que des impasses. Je suis d'accord avec l'évaluation selon laquelle ce contrôle n'était pas destiné à gérer ces nombreuses options et un autre contrôle serait mieux adapté.

@nickwynja , prendra votre recommandation d'indicateur occupé avec le design et verra ce qu'ils disent.

Merci encore à tous !

Fermeture de ce problème car aucun test d'assurance qualité n'est impliqué. S'il vous plaît voir les commentaires pour plus d'informations.