我已经构建了一个列表/编辑屏幕,最多可包含200行(100“列表”行和100“详细”行).
每个“细节”行包含一个完整的HTML表单 – 默认情况下它们(在Bootstrap“Collapse”组件内)隐藏,直到用户开始编辑它们.
请注意,这是一项学习练习;在我开始看到性能问题之前,我试图了解在UI的复杂性方面可以推动React的程度.
我不是专门为这个页面寻找解决方案 – 我可以做很多UX事情,限制每页行数,将细节分成自己的屏幕,使用模态对话框等.
列表和详细信息组件实现为“PureComponent”,涉及的状态对象都是不可变的Typescript对象(列表使用Immutable.js实现).
我估计有大约1500 – 2000个React组件涉及渲染这个页面.
我很满意这个实现背后的代码复杂程度 – 它易于阅读和更改,我相信在真正的应用程序中,随着复杂性的增加,实现将保持可维护性.
但表现并不是我所希望的.
我正在使用带有“？react_perf”网址的Chrome效果标签来衡量此页面.
通过100个实体,Chrome中的“用户计时”向我显示“表[更新]”占用60-90毫秒.
这似乎是相当长的一段时间,我知道这些数字并不能代表生产性能,因为我正在使用React的开发版来完成性能计时.
当应用程序编译生产时,应用程序的性能会更好 – 在相当标准的桌面企业计算机或iPhone6上,性能都可以.如果你真的在寻找它,你可以看到滞后,但它几乎没有引人注意.
但在速度较慢的硬件(三星Galaxy平板电脑和旧款三星手机)上,滞后非常明显.
我试图了解我是否应该寻找重大错误/瓶颈,或者这是关于我应该期待的这么多组件的性能？
可能的改进：
>我可以做的显而易见的主要事情是通过不渲染所有这些细节形式来减少React组件的数量,除非用户扩展实体
>这肯定会提高性能 – 表格更新时间可以降低到大约20-30毫米的开发时间,尤其是在生产中几乎检测不到.
>人们不可避免地会建议使用Redux
>如果我这样做,你会期望看到什么样的性能提升？
>我的猜测是Redux实现对性能实际上并没有太大作用(除非我犯了一些重大错误,Redux将指导我避免)
所以问题是：
“what is a reasonable upper limit for the number of components a React
page should have”?
或者：
“is 50+ milliseconds to do an update reasonable for a screen of this size”?
如果我的实施不是非常不正确,那么这个练习让我觉得我的一般性能指导是：
>“尝试在任何给定的屏幕上保持低于约500个React组件”
我认为您的特定场景的基准测试是必须的.确保正确地键入元素,并尽可能手动实现shouldComponentUpdate以进行快捷方式.