Enterprise: 下拉/多选：重构以使用数据源对象而不是选择元素

注意：此问题可能会解决 #843（和其他）中确定的一些性能问题。

您的功能请求是否与问题有关？
我们与 IDS 一起发布的当前 Dropdown/Multiselect 是作为标准 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章 最新

其中许多问题留下了“这仍然不是很好但更好”的警告。 这样做的原因是因为其核心的下拉/多选设计不适合这么大的数据集。 如果我们想解决性能问题，我们需要解决其设计的基础问题。

描述您想要的解决方案
修复下拉/多选性能的可能解决方案路径：

• [ ] 使用<select>作为主要数据源的硬性要求。 #267 的一些最新改进开始绘制出 AJAX 调用如何为 Dropdown 生成数据对象，我们可以将其存储在客户端上。 我认为我们应该转向使用具有一些简单状态（禁用/选择/等）的对象作为组件行为的主要驱动程序，而不是从 DOM 元素中获取这些信息。 <select>标签及其<option>的渲染对于表单提交之类的事情仍然是必要的，但我们应该将数据对象定义为“真实来源”，并绘制 select 标签基于对象（反之亦然）。
• [ ] 还探索在任何意义上都不渲染/依赖于<select>标记。 对于开发人员来说，使用带有这么多项目的下拉/多选来简单地拦截表单提交请求，并发送数据源对象的状态而不是依赖于正常的表单提交过程，这可能是一个合理的用例。 目前，这种类型的使用是不可能的。
• [ ] 一旦我们不再依赖 DOM 元素，我们就可以开始探索在任何给定时间仅在 DOM 中显示列表项的子集。 由于状态由数据源对象保留，DOM 不一定重要，当用户滚动列表时加载/卸载少量列表项应该更简单（将允许我们探索 #460 on落下）。
• [ ] 为大型数据集的服务器端处理创建更好的建议。 即使在具有这么多记录的客户端对象中保留状态最终也会变得非常慢。 我们可能希望有一个建议和/或一些演示，说明我们可能希望 IDS 的实现如何处理服务器上的下拉/多选记录。

描述您考虑过的替代方案
我们过去提出的一些其他想法：

• 一个更简单的组件，它覆盖<select>标记并设置它们的样式，而不是为交互生成伪标记。 这可能能够更好地处理更大的列表，因为它不会复制它。 在这种情况下，我们仍然必须一次处理 2000 个元素。