关于做好React项目,你需要知道的几点最佳实践

·  阅读 1839
关于做好React项目,你需要知道的几点最佳实践

携手创作,共同成长!这是我参与「掘金日新计划 · 8 月更文挑战」的第 12 天,点击查看活动详情

你真的会用 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,及时制止项目成员各自造轮子。
最好的模块管理,就是保持整个项目中实现某类功能的方式始终只有一个。

管理好文件夹

让项目变复杂的另一个情况是乱糟糟的文件夹。
我把项目复杂度分为三级,每一级使用的文件夹管理策略不同。
复杂度划分的参数有很多,这里不展开讲了。
最简单的方式是按照页面数量划分。比如:

  1. 中小型项目,50 个页面以内。
  2. 大型项目,50-500 个页面。
  3. 超大型项目,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 项目的。
如果对你有所帮助,欢迎点赞。

分类:
前端
收藏成功!
已添加到「」, 点击更改