React 性能：什么是组件数量上限的好指南？
我正在使用 React、Bootstrap 和 Typescript。
我构建了一个列表/编辑屏幕，最多可以包含 200 行（100 个“列表”行和 100 个“详细信息”行）。每个“详细信息”行都包含一个完整的 HTML 表单——默认情况下它们是隐藏的（在 Bootstrap“折叠”组件内），直到用户开始编辑它们。
请注意，这是一个学习练习；在我开始看到性能问题之前，我试图了解在 UI 的复杂性方面我可以将 React 推多远。我不是专门为此页面寻找解决方案 - 我可以做很多 UX 事情，限制每页的行数，将详细信息拆分到自己的屏幕中，使用模式对话框等。
列表和细节组件实现为“PureComponent”，涉及的状态对象都是不可变的 Typescript 对象（列表使用 Immutable.js 实现）。我估计大约有 1500 - 2000 个 React 组件参与渲染这个页面。
我对这个实现背后的代码复杂程度感到非常满意——它很容易阅读和更改，我相信在真正的应用程序中，随着复杂性随着时间的推移而增加，实现将保持可维护性。
但表现并不完全是我所希望的。我正在使用带有“?react_perf” URL 的 Chrome 性能选项卡测量此页面。
对于 100 个实体，Chrome 中的“用户计时”显示“表 [更新]”需要 60 - 90 毫秒。
这似乎很长一段时间，我知道这些数字并不代表生产性能，因为我使用的是 React 的开发版本来进行性能计时。并且该应用程序在编译用于生产时确实表现更好 - 在相当标准的桌面企业机器或 iPhone6 上的性能还可以。如果你真的在寻找它，你可以看到延迟，但它几乎不明显。但是在较慢的硬件（三星 Galaxy 平板电脑和旧三星手机）上 - 延迟非常明显。
我试图了解我是否应该寻找主要错误/瓶颈，或者这是否与我应该对这么多组件期望的性能有关？
可能的改进：
- 我能做的显而易见的主要事情是通过不渲染所有这些细节表单来减少 React 组件的数量，除非用户扩展实体
- 这肯定会提高性能 - 表更新时间在开发中减少到大约 20 - 30 毫秒，几乎无法检测到，尤其是在生产中。
- 人们不可避免地会建议使用 Redux
- 如果我这样做，您希望看到什么样的性能提升？
- 我的猜测是 Redux 实现实际上对性能没有太大作用（除非我犯了一些重大错误，Redux 会引导我避免）
所以问题是：
“React 页面应具有的组件数量的合理上限是多少”？
或者：
“对于这种尺寸的屏幕进行 50+ 毫秒的更新是否合理”？
如果我的实现不是非常不正确，那么这个练习让我认为我的一般性能指导是：
- “尽量在任何给定屏幕上保持低于 500 个 React 组件”