Enterprise: Раскрывающийся список/множественный выбор: рефакторинг для использования объекта источника данных, а не элемента Select.

ПРИМЕЧАНИЕ. Эта проблема потенциально устраняет некоторые проблемы с производительностью, указанные в № 843 (и других).

Ваш запрос функции связан с проблемой?
Текущий Dropdown/Multiselect, который мы поставляем с IDS, был создан как слой взаимодействия поверх стандартного HTML-элемента <select> , обрабатывающий выбор его параметров как в одиночных, так и в множественных настройках.

Варианты использования этого компонента со временем расширились и теперь включают фильтрацию доступных параметров, что привело к тому, что команды использовали раскрывающийся список/множественный выбор для очень больших наборов данных (в некоторых случаях более 2000 элементов за раз). Хотя наша команда настаивает на том, что мы не рекомендуем использовать этот компонент для таких больших наборов данных, мы продолжаем получать проблемы, требующие решения проблемы производительности на этих уровнях. Некоторые предыдущие проблемы, которые мы исправили, включают:

• https://jira.infor.com/browse/SOHO-5693
• https://jira.infor.com/browse/SOHO-5192
• https://jira.infor.com/browse/SOHO-7816
• #843 является последним

Многие из этих проблем оставляют оговорку «это все еще не очень хорошо, но уже лучше». Причина этого в том, что дизайн Dropdown/Multiselect по своей сути не подходит для таких больших наборов данных. Если мы хотим исправить проблемы с производительностью, нам нужно обратиться к основам его дизайна.

Опишите желаемое решение
Возможный путь решения для исправления производительности Dropdown/Multiselect:

• [ ] Жесткое требование использования <select> в качестве основного источника данных. Некоторые недавние улучшения из # 267 начали отображать, как вызов AJAX может генерировать объект данных для раскрывающегося списка, который мы можем сохранить на клиенте. Я думаю, что мы должны перейти к использованию объекта с некоторыми простыми состояниями (отключено/выбрано/и т. д.) в качестве основного драйвера поведения компонента, вместо того, чтобы получать эту информацию из элемента DOM. Рендеринг тега <select> и его <option> по-прежнему будет необходим для таких вещей, как отправка формы, но мы должны определить объект данных как «источник правды» и нарисовать тег select. на основе объекта (а не наоборот).
• [ ] Также исследуйте просто отсутствие рендеринга/зависимости от тега <select> в любом смысле. Для разработчика, использующего Dropdown/Multiselect с таким количеством элементов, может быть разумным вариантом просто перехватить запрос на отправку формы и отправить состояние объекта источника данных вместо того, чтобы полагаться на обычный процесс отправки формы. В настоящее время этот тип использования невозможен.
• [ ] Как только мы перестанем полагаться на элемент DOM, мы сможем начать изучать отображение только подмножества элементов списка в DOM в любой момент времени. Поскольку состояние сохраняется объектом источника данных, DOM не обязательно имеет значение, и должно быть гораздо проще загружать/выгружать небольшое количество элементов списка, когда пользователь прокручивает список (что позволило бы нам изучить # 460 на Падать).
• [ ] Создание лучших рекомендаций по обработке больших наборов данных на стороне сервера. Даже сохранение состояния в объекте на стороне клиента с таким количеством записей может в конечном итоге стать очень медленным. Мы могли бы захотеть получить рекомендацию и/или несколько демонстраций того, как мы можем захотеть, чтобы реализации IDS обрабатывали записи Dropdown/Multiselect на сервере.

Опишите альтернативы, которые вы рассматривали
Некоторые другие идеи, которые мы обсуждали в прошлом:

• Более простой компонент, который накладывает теги <select> и стилизует их вместо создания псевдоразметки для взаимодействий. Это могло бы лучше обрабатывать больший список, поскольку он не дублировал бы его. В этом случае нам все равно придется обрабатывать 2000 элементов одновременно.