Enterprise: 当下拉列表包含 +500 个选项时，多选下拉控件在 IE11 中的性能很差

对我来说，我们对此的测试结果似乎比这些数字要好得多。
http://master-enterprise.demo.design.infor.com/components/dropdown/test-2000-items.html

Pehaps 多选特别存在问题。 它们具有相同的代码，但有一些不同的路径。

最后你有测试代码吗？ 还是很多下拉？

@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 个选择可能更适合决策/选择 UI。

我们可能可以让它更快，但想知道用例是否会更好地由不同的组件提供服务。

它肯定会由不同的组件提供更好的服务，但客户要求使用下拉列表。 我们是否想回过头来说，这不是正确的组件，您将在 IE11 中遇到问题……也许升级到 Edge？ 我想我们可以提供建议。

@tmcconechy ，对于我们的应用程序，我们有 4 个多选下拉控件，用户可以访问这些控件以过滤订单列表页面上的结果。 这些下拉列表中显示的选项数量基于用户选择以及授予用户的权限（角色）。 普通用户只能看到一小部分选项。 一旦他们做出选择，我们就会有一个 API 调用，它会在用于额外过滤的辅助下拉控件中填充更多选项。 （这些下拉菜单相互通信。）

具有完全管理员权限的用户将看到下拉控件中的所有选项。 目前，选项的总数是 1969。这个数字可以增长，具体取决于客户想要使用的内容。

一个用户可能只能在控件中看到 2-50 个选项，但如果他们被授予额外的权限，他们拥有的选项数量可以扩展到 1969。我们不想提供另一个控件（例如产品查找），它添加了一个当多选控件是最佳选项时，特别是当大多数用户会看到较少数量的选项时，他们与他们进行交互并执行过滤过程的额外步骤。

处理 IE11 令人沮丧，我知道当控件中有这么多选项时，性能并不是最佳的。 这个相同的控件，在没有“多个”设置的情况下使用，并且当有大约 2000 个选项时，在 IE11 中只有一个选择下拉列表没有相同的性能问题。 只有作为多选才会有这么大的性能问题。

我也希望它就像告诉他们升级浏览器一样简单，但这个应用程序是为主要使用 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

最好的体验是等待一秒钟左右，如果列表尚未出现，则仅显示忙指示符。

在最近的 macOS 上的 Chrome 中检查后，下拉列表与多选response()执行时间的差异。 请注意单位。
下拉：512.14 毫秒
多选：1.02 秒

@tmcconechy @davidcarlsonberg @EdwardCoyle @clepore我感谢每个人都在研究这个问题。 特别是@davidcarlsonberg ，感谢您花时间在这上面。 我们已经尝试了将近 2 周的时间来优化 IE11，但只遇到了死胡同。 我同意这样的评估，即此控件并非旨在处理这么多选项，而另一个控件会更适合。

@nickwynja ，会将您繁忙的指标推荐与设计结合起来，看看他们怎么说。

再次感谢大家！

关闭此问题，因为不涉及 QA 测试。 请参阅评论以获取更多信息。