React Page建议将逻辑保持在较高水平

我已经阅读了很多最近尝试学习反应和最佳实践的内容,并且我反复提到建议说"尽量保持你的逻辑在链中尽可能高".

我不明白为什么这是一个建议.我理解这简化了代码,但我不认为这对于那些变得庞大而复杂的项目来说一定是好的做法.我也明白,反应背后的意识形态是"dom很慢,javascript很快",并且重写shadow-DOM和'diff'ing它可以更快地重新渲染到DOM,但它似乎是对计算的巨大浪费时间.当一个项目变得更具交互性和更具动态性时,它似乎会重新计算一些可能是长列表的东西,例如1000多个项目,并且会浪费cpu而不仅仅是检查(添加,移动,移除等). .)这将大大减少CPU.

Facebook推荐的算法方法背后有原因吗？

我不确定这些建议是否必然针对人们构建极其庞大和复杂的应用本身,尽管这不是坏建议,我个人仍然认为集中状态操作逻辑(例如,磁通或其他类似的"外部" 是一个好主意反应"模式".我认为这个建议特别针对React的新手,鼓励他们开发一种思考写作惯用的React代码的方法:

来自更高级别组件的状态通过道具流入儿童.

较低级别的组件通过调用通过props传递的回调来影响数据.

拥抱React的声明性编程模型,让虚拟DOM尽可能地处理.

整个组件层次结构中没有与业务域相关的逻辑; 试着把它移到顶端.

同样,不要在整个组件层次结构中散布与业务域相关的状态; 保持它顶部(或者,正如我所提到的,完全在React之外).

根据我的经验,遵循这些建议可以使代码库更易于理解并且易于更改,尤其是随着代码库的大小和复杂性的增加.

但是,与任何其他建议或"最佳实践"一样,这并不意味着您不应该批判性地分析它.如果您有一个包含1000个项目的列表并且性能正在成为一个问题,那么当然可以将该逻辑转移到更好的位置,实现缓存或降级到更低级别的API.但我仍然认为这个建议总的来说是好的- 如果表现真的是一个问题我只会做那些事情.太多人忘记了引用的其余部分:

我们应该忘记小的效率,大约97%的时间说:过早的优化是所有邪恶的根源.然而,我们不应该放弃那个关键的3%的机会.