持续创作，加速成长！这是我参与「掘金日新计划 · 10 月更文挑战」的第4天，点击查看活动详情

前言

承上文react指北：你真的会用hooks吗-下篇。

前面我们讲了一些hooks在react中的使用，以及如何通过hooks封装来减少react组件的复杂度，但是如果要写好一个维护性比较高的组件，单凭这些还是不够的。所以今天我们接着来讲讲，我们还能做些什么让react的组件变的更清晰。

不可缺少的hooks封装

前面几篇文章我们已经用了较多的篇幅去讲hooks封装的必要性以及如何去封装一个hooks，这里就不再展开讲了。有兴趣的可以去翻阅我之前写的文档。

react指北：你真的会用hooks吗-上篇

react指北：你真的会用hooks吗-中篇

react指北：你真的会用hooks吗-下篇

纯函数的使用

hooks的封装其实是很多人在优化react组件中首先会去做的一件事情（当然做的好不好就另说了）。然而除了hooks的封装以外纯函数的使用也很重要。

关于纯函数的定义，不了解的可以自行搜索下，这里就不展开了。

纯函数其实很简单，但是实际业务中，除了个别经验相对丰富的同学会稍微有意识的去使用纯函数之外，其他人几乎不会想到在组件中较多的使用纯函数。原因我总结起来大概有以下几点：

1. 个人习惯上，直接就在组件内部定义方法和逻辑，顺手就引用了props和state的值。
2. 主观上觉得这个方法不具备可复用性，不需要从组件中抽离。
3. 没有使用纯函数的习惯，只要变量能访问到，绝对不传参。

当然，我个人也觉得，如果组件的逻辑足够简单的话，可以不需要使用纯函数将组件的逻辑抽离在外层，但是当你的组件逻辑足够复杂的时候呢？

在我看来，当组件内部方法的声明过多的时候，至少会有以下几个问题：

1. 组件内部方法直接访问props和state，数据和逻辑高度耦合，甚至有时候不同方法组件的逻辑也高度耦合，后续业务改造的时候如果想要拆分很难把某个逻辑从组件中拆分出去，经常会出现，实际我只想把某个方法迁移出去，但是却因为方法依赖了其他方法或者属性，不得已要把一整块都挪走，但是整块改的话风险又太大，最后只能原地不动，任凭组件越来越大（如果你的团队在使用ts，且几乎什么any的情况下还好，否则，就只能呵呵了，谁动谁die）。
2. 组件的代码量会急剧增加，视图和逻辑混杂在一起，代码的阅读成本变高，不利于后续维护。可能一个小功能的改动也需要很久。 我大量的经验观察来看，其实useCallback过多是组件粒度变大的最大原因。
3. 和class component不同，fc会在每次render的时候都重新走一遍组件内部所有的变量声明和hooks，如果你的组件内部有大量的方法声明，那么render的时候这部分的开销也会变大，组件性能会降低（大部分情况下单个组件变量声明的性能开销在一次render中是可以被接受的，但是随着组件的复杂度提高，内部子组件增多，方法多的情况下性能开销个人认为还是值得考虑的，不过我没有做过这部分的性能测试，有兴趣的可以帮忙测试下然后贴在评论区。）。

所以现在开始请在日常开发中更多的使用纯函数来避免上述的问题出现。

这几乎不需要你有任何额外的知识，只需要你在开发的时候把方法声明挪到组件外围，之后通过参数传递的方法来访问state和props。

（什么，你需要在方法中访问setState？那么你可以把setState一起传进去，或者考虑使用自定义hooks）

适当的使用redux或者mobx等工具收敛你的业务逻辑

在hooks出现之前，redux或者mobx几乎是开发react大型应用不可缺少的工具。但是当hooks出现之后，部分团队逐渐弱化了redux和mobx的使用，甚至有团队全靠context和hooks来组织数据，来发挥hooks的最大优势。

当然，这也是可以的，但是在我日常的工作经验中来看，合理的使用redux和mobx来优化你的数据和业务逻辑管理依然是很有必要的，他会让你的组件更加清晰，可维护性更强（毕竟我再也不需要在组件里面找逻辑了，并且我永远知道当前依赖的状态是在哪声明的，以及它的使用范围，而不需要满世界找useState）。

具体用法就不阐述了，可以参阅文档。

补充说明一下什么才叫合理：

个人认为，当某个状态需要在两个以上组件中共享的时候，你就该考虑使用状态管理工具了。

补充一点，在用redux或者mobx的时候，请合理拆分state的粒度。

合理的拆分视图层

我见过很多组件，视图层的代码有几百行之多，在我看来，这已经是到了难以维护的地步了。恕我直言，不管是什么组件，我都没有任何兴趣去看那一堆的div，阅读视图可比阅读逻辑还要复杂和抽象多了。如果这个组件一直是我维护的还好，否则我根本分不清具体哪行html是我想要修改的。此外，随着html的增多，你也真的很难说，两个div之间是不是就完全没有耦合，他们看上去应该是解耦的，实际却耦合了（是的，你没看错，写html也是有耦合一说的）。

并且视图层的复杂，也意味着你组件逻辑的复杂度和性能都在下降（不清楚原因的可以去看下组件的渲染和diff规则，不展开）。

而当我们拆分成小组件的时候，上面这些问题，基本都能解决（不能保证百分之百，但是百分之九九以上吧）。

在我看来一个合理的组件，逻辑处理代码量应该尽量不超过200-300行，视图层的元素尽量维持在20个以内，超过的话，就需要考虑将组件拆分成多个小组件来维护了。

什么，你觉得这样会让业务逻辑变割裂？无法在一个组件中阅读完全部的逻辑？

那么你要不要考虑一下把所有代码都放在一个文件里面，这样就一点都不割裂了。

总结

要保持个人react组件的清晰，你需要牢记上面几条，并且在平时工作中不断总结优化。而需要保持团队的react组件清晰，你还需要一套符合你团队的react代码规范和一个合理的cr流程。

听我一句劝，真的不要把所有逻辑都堆在一个组件里面了，不然你的代码真的会变得无法维护。

另外，欢迎大家在评论区交流讨论。