Enterprise: Выпадающий элемент управления множественным выбором имеет низкую производительность в IE11, когда раскрывающийся список содержит +500 вариантов

Результаты нашего теста кажутся мне намного лучше, чем эти цифры.
http://master-enterprise.demo.design.infor.com/components/dropdown/test-2000-items.html

Возможно, есть проблема с множественным выбором. У них один и тот же код, но несколько разных путей.

В итоге тестовый код был у вас? Или много выпадающих?

@tmcconechy , для тестирования у меня есть 5 элементов управления множественным выбором на странице. Когда я меняю эти элементы управления на раскрывающийся список (без множественного выбора), я замечаю значительное улучшение производительности. Эта проблема кажется специфичной для элементов управления множественным выбором.

Обсуждая эту проблему, вам немного интересно узнать о реальном варианте использования? Какие варианты множественного выбора делает пользователь?

@picitelli - лучший человек, с которым можно поговорить.
Насколько я понимаю, список должен формироваться каждый раз, когда раскрывающийся список задействован, и в нем может быть до 2000 элементов в зависимости от роли пользователя. Им нужно перезагружать раскрывающийся список в точках, но они не могут взаимодействовать с плагином от Mongoose.
Не уверен, что делается выбор из нескольких вариантов.
Я много читал о низкой производительности IE11 при добавлении элементов в DOM в целом, и я буду включать некоторые ссылки ниже.
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 медленно работает с DOM, но мне было интересно, в каком фактическом случае пользователю показывают 500 вещей, и он должен выбирать, какие из них. Похоже, что для пользовательского интерфейса принятия решения / выбора было бы более подходящим максимум 50 вариантов.

Мы, вероятно, сможем сделать это быстрее, но нам интересно, будет ли вариант использования лучше обслуживаться другим компонентом.

Это наверняка лучше обслужил бы другой компонент, но клиент просит использовать раскрывающийся список. Хотим ли мы вернуться и сказать, что это не тот компонент, и вы столкнетесь с проблемами в IE11 ... может быть, обновитесь до Edge? Полагаю, мы могли бы предложить такое предложение.

@tmcconechy , для нашего приложения у нас есть 4 раскрывающихся элемента управления с множественным выбором, к которым пользователь может получить доступ для фильтрации результатов на странице со списком заказов. Количество параметров, отображаемых в этих раскрывающихся списках, зависит от выбора пользователя, а также от разрешений (роли), которые ему предоставлены. Обычный пользователь будет ограничен только небольшим набором опций. После того, как они сделают выбор, у нас есть вызов API, который заполняет дополнительные параметры во вторичном раскрывающемся списке, используемом для дополнительной фильтрации. (Эти раскрывающиеся списки взаимодействуют друг с другом.)

Пользователь с полными правами администратора увидит все параметры в раскрывающемся списке. На данный момент общее количество опций составляет 1969. Это число может расти в зависимости от того, что клиент хочет использовать.

Пользователь может видеть только 2-50 опций в элементе управления, но если им предоставлены дополнительные разрешения, количество имеющихся у них опций может увеличиться до 1969. Мы не хотим предлагать другой элемент управления (например, поиск продукта), который добавляет дополнительный шаг для их взаимодействия и выполнения процесса фильтрации, когда элемент управления с множественным выбором является лучшим вариантом, особенно когда большинство пользователей увидят меньшее количество вариантов.

С IE11 сложно иметь дело, и я знаю, что производительность не оптимальна, когда в системе управления так много опций. Тот же самый элемент управления, используемый без параметра «несколько», и как раскрывающийся список только для одного выбора, не имеет таких же проблем с производительностью в IE11, когда есть ~ 2000 вариантов. Только при множественном выборе возникает эта большая проблема с производительностью.

Я также хотел бы, чтобы это было так же просто, как сказать им обновить свой браузер, но это приложение предназначено для клиентов-клиентов, которые в основном используют IE11.

@tmcconechy @EdwardCoyle
Я работал с различными решениями для оптимизации этого кода для IE и не встречал ни одного решения, которое после реализации увеличивало бы производительность в IE11. На этом этапе я рекомендую отступить и предложить другой компонент, если им нужна более высокая производительность. На данный момент раскрывающийся список и множественный выбор очень хорошо работают с до 500 элементами. 2000, как это предлагается в этом выпуске, мне показалось бы избыточным для такого компонента.
Рад получить любой совет или обсудить помимо этой ветки комментариев.

@picitelli, если нас просят поддержать IE11 в этих условиях, решение непростое. Наш компонент Dropdown потребует довольно серьезного пересмотра, поскольку он никогда не проектировался с учетом такого типа нагрузки.

@davidcarlsonberg @clepore @nickwynja @tmcconechy мы должны поговорить об этом. У меня есть некоторые идеи по поводу производительности, но эти идеи попадают на территорию «рефакторинга».

Я думал, что есть большая разница между выпадающим списком с 2000 и множественным выбором с 2000. Вы исследовали разницу в скорости для более быстрого улучшения.

Я больше искал основную причину снижения производительности. Я могу исследовать раскрывающийся список множественного выбора и простой раскрывающийся список, если мы хотим изменить область действия этого билета, чтобы увидеть, что там можно получить для быстрой победы.

Да, это определенно стоит посмотреть, я основывал это предположение на этом комментарии https://github.com/infor-design/enterprise/issues/843#issuecomment -424495956

Все может помочь, даже если это «немного» быстрее

Я продолжу определение и улучшение разницы между раскрывающимся списком и множественным выбором.

Я думаю, что @EdwardCoyle прав в том, что нам нужно будет пересмотреть это с нуля, используя более современные методы для повышения эффективности. Я не уверен, стоит ли тратить на этот @davidcarlsonberg больше дня.

@picitelli Мы продолжим искать варианты решения этой проблемы с повышением производительности.

Я думаю, что лучший вариант для этого случая - использовать индикатор занятости :

Индикатор занятости уведомляет пользователя о том, что система обрабатывает запрос и что они должны дождаться обработки этого запроса, прежде чем продолжить выполнение текущей задачи.

Вот пример его использования в поле:

• 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

Лучше всего подождать секунду или около того и отображать индикатор занятости только в том случае, если список еще не появился.

После проверки в недавнем Chrome на macOS разница в раскрывающемся списке и во времени выполнения множественного выбора response() . Обратите внимание на единицы измерения.
раскрывающийся список: 512,14 мс
множественный выбор: 1.02 с

@tmcconechy @davidcarlsonberg @EdwardCoyle @clepore Я благодарен всем, кто занимается этой проблемой. Особенно @davidcarlsonberg , спасибо, что потратили на это время. Мы почти две недели пытались оптимизировать для IE11 и ни разу не попали в тупик. Я согласен с оценкой, что этот элемент управления не предназначен для обработки такого количества вариантов, и что другой элемент управления будет лучше подходящим.

@nickwynja , свяжется с вашей рекомендацией индикатора занятости с дизайном и посмотрит, что они говорят.

Еще раз всем спасибо!

Закрытие этой проблемы, так как тестирование QA не проводится. Пожалуйста, смотрите комментарии для получения дополнительной информации.