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

React Page recommends keeping logic at a high level

本文关键字：高水平 Page React 更新时间：2023-09-26

我最近读了很多东西，试图学习反应和最佳实践，我多次遇到建议说"尽量保持你的逻辑在链中的高度"。

我不明白为什么这是一个建议。我知道这在很大程度上简化了代码，但我不认为这对变得庞大和复杂的项目来说一定是好的做法。我也理解react背后的思想是"dom是慢的javascript是快的"，重写影子dom并"区分"它可以更快地重新渲染到dom，但这似乎是在浪费计算时间。当一个项目变得更具交互性和动态性时，它似乎会重新计算一些可能是长列表的东西，比如1000多个项目，并且会浪费cpu，而不仅仅是检查（添加、移动、删除等），这会大大减少cpu。

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

我不确定的建议是否一定是针对构建极其庞大和复杂的应用程序的人，尽管这不是一个坏建议，我个人仍然认为集中状态操作逻辑（例如流量或其他类似的"React之外"模式）是个好主意。我认为这个建议特别针对刚接触React的人，鼓励他们开发一种思考编写惯用React代码的方法：

来自更高层次组件的状态通过道具渗透到孩子身上
较低级别的组件通过调用通过props传递的回调来影响数据
接受React的声明性编程模型，让虚拟DOM尽可能多地处理
不要在整个组件层次结构中都有与业务域相关的逻辑；试着把它移向顶端
同样，不要在组件层次结构中散布与业务域相关的状态；将其保持在顶部（或者，正如我所提到的，完全在React之外）

根据我的经验，遵循这一建议可以让代码库更容易理解和易于更改，尤其是，因为代码库的大小和复杂性都在增长。

但就像任何其他建议或"最佳实践"一样，这并不意味着你不应该批判性地分析它。如果您有一个1000项的列表，并且性能正在成为一个问题，那么当然可以将该逻辑转移到更好的位置，实现缓存，或者降到更低级别的API。但我仍然认为这个建议总体上是好的——只有当性能真的是个问题时，我才会这么做。太多人忘记了这句话的其余部分：

我们应该忘记小效率，比如说大约97%的时间：过早优化是万恶之源。然而，我们不应该在关键的3%中放弃我们的机会。