你真的会用 React 做项目吗？
使用 React 编写代码并不难，但是使用 React 做好项目可不容易。
很多人在刚开始做 React 项目时感觉一切井井有条，但是随着时间的推移，项目规模越来越大，到最后各种 Bug 频出，样式错乱，文件找不到等问题全部暴露出来了。
归根结底，是你只学会了如何使用 React 和相关库的 API，但是没学会如何将 React 应用到实际场景，做好项目复杂度管理。
遵循合理的最佳实践，可以帮你做好一个项目，这主要体现在维护方面，可能在刚开始你会觉得有些厌烦，好像是在增加一些工作量。但实际上不是这样，我们开发一个功能所消耗的时间在整个项目生命周期中不值一提，更多的时间是在维护，是在修改功能。这才是最浪费时间的地方。
下面是我在使用 React 开发大型项目时总结的一些经验和教训，希望对你能够有所帮助。
注：文中内容并不仅限于 React，最佳实践其他类似的框架也通用。
不要忽略状态管理这件事
在项目刚开始的时候，页面复杂度并不高，在单个组件中维护状态行得通。但是当我们遇到下面这几种情况时，就会让数据流变得一团糟：
- 多个组件的状态同步
- 子组件通过 props 去操作父组件的状态
- 跨多级组件传递状态。
所以我建议任何项目都应该从状态管理开始。
现在 React 的状态管理方案已经非常成熟了，像 Redux、Mobx、Recoil、xState 都很完善。而且还有像 RTK 这种工具，可以让我们管理状态更加简单。
如果你不喜欢使用第三方库，或者项目确实非常小，也可以使用 React 自身的 Context 和 useReducer Hook，它们也可以处理状态管理。
一旦使用了状态管理工具，就可以将逻辑从组件中抽离出来，再也不会有上千行的组件了。
不要忽略类型的作用
相信你一定碰到过，因为某个数据类型不对或者某个属性名拼写错误而抓耳挠腮，花了大量时间去调试代码，但最终发现原来是这种微不足道的错误导致的问题。这是 JavaScript 这门弱类型语言决定的。
所以我建议使用 TypeScript，它可以帮助我们规避掉绝大部分因为粗心导致的错误，让我们更加聚焦到功能的开发上。
如果你的项目实在很小，而且非常不喜欢使用 TypeScript，那我建议使用 PropTypes。
不要自己封装公用函数
无论是 JavaScript，还是 React。它们的生态都非常丰富，社区中有大量的库来帮我们解决各式各样的问题。
比如：
- 处理时间的库：day.js。
- 处理数据的库：lodash。
- 处理表单的库：formik。
- 处理数据请求的库：SWR、axios。
还有一些大而全的库，一个库搞定你碰到的所有需求。
可能你会问，我们一直使用开源的库，是不是对技术没有提升？
从个人角度上考虑，是的。
但是从工程角度考虑，统一实现方式，统一使用成熟的库，风险会更低。
如果想学习技术，可以自己在项目外去实现一些常见的库，或者读源码、参加开源项目都可以。但是真的不推荐在有成熟开源库的情况下还在项目中自己封装。
如果你是 Leader，也一定要有这种意识。定期 CodeReview，及时制止项目成员各自造轮子。
最好的模块管理，就是保持整个项目中实现某类功能的方式始终只有一个。
管理好文件夹
让项目变复杂的另一个情况是乱糟糟的文件夹。
我把项目复杂度分为三级，每一级使用的文件夹管理策略不同。
复杂度划分的参数有很多，这里不展开讲了。
最简单的方式是按照页面数量划分。比如：
- 中小型项目，50 个页面以内。
- 大型项目，50-500 个页面。
- 超大型项目，N个系统，超过 500 个页面。
第一级
中小型项目，应该按照代码功能来划分文件夹，不要按照文件的职责划分文件夹。
什么意思呢？
我们可以有 pages、components、apis 这种文件夹。
但是不要有 js、css、json 这种文件夹。
Next.js 的项目文件管理是一个非常不错的案例，可以多去参考。
第二级
大型项目。
这时项目规模在持续扩张后，目录也要持续升级。
此时最佳实践是：按业务功能领域去拆分文件夹，和某个业务领域相关的所有页面、组件、路由、状态、样式、接口都放在一起。而不是再遵循按代码功能拆分的策略了。
如果需要共享代码，通过定义接口的形式。
这一点有点类似于 DDD 的理念。
第三级
超大规模项目。比如超过 500 个复杂页面的项目。
需要按照领域模块进行拆分成多仓库，每个仓库中仍然采取第二级的文件划分。
除了拆分多个仓库以外，也可以使用 monorepo。
选择适合自己的组件库
如果是 B 端项目，公司有组件库最好，没有的话，可以找一个开源组件库。资源允许也可以自研组件库。
根据我研发组件库的经验，覆盖项目 95% 场景的 80+ 组件库，4 个人全职 2-3 个月大概就能开发出来。假设平均人月投入是 2-3 万。成本至少需要 20 万+。当然这只是开发成本，组件也需要定期维护和修复。
如果你能负责这件事，一定要和高级别 Leader 沟通清楚预算，不能因为投入问题半途而废。
如果这件事情开始了，一定要和设计师保持高度沟通，不能埋头苦干，组件库是设计师和工程师合作结果。
如果不能自研组件库，那就寻找成熟稳定的开源组件库。
React 的开源组件库大大小小不下几百个，值得推荐的有：
- mantine
- Antd
- Mui
如果是 C 端项目，建议使用 TailwindCSS。
多人协作维护公用样式绝对是一件非常困难的事情，发展到最后很容易变成各写各的。
利用 Hook 包装数据请求
这是一个关于代码比较具体的最佳实践。
如果要在组件中请求数据，那可以自己包装一个 Hook，而不需要将 useEffect、useState、useMemo 这些低级 API 放在组件的代码中，这也算是分离关注点的一个做法。
这一点，SWR 就做得很好。
总结
上面是我在管理 React 项目时的一些最佳实践。其实关键原则就那么几点：
- 高内聚低耦合可扩展
- 分离关注点，降低心智负担
- 持续降低复杂度
每个人都有自己的最佳实践，你也可以分享一下自己是如何管理 React 项目的。
如果对你有所帮助，欢迎点赞。
