可维护的 React 程序之项目结构梳理

1,679 阅读5分钟
原文链接: zhuanlan.zhihu.com

很少很少见过有人讨论「项目结构」这个话题,究其原因是大部分同学认为这并不如写代码重要。

有趣的是 JS 在 Node 加持的前端中,文件作为一个「模块」的方式已经深入了前端开发的各个层面,简单的来说就是:一个文件可以被称为一个模块。如何组织项目中的文件目录,文件摆放位置,变得极其重要。

稍有不慎,模块和模块之间的划定、引用就会变得乱七八糟。很多人尝试在代码中寻求可维护性的突破,然而却忘了项目结构给维护性带来的巨大变化。今天我们的切入点就是 React 项目的结构梳理

强制规划目录划分

人,是懒惰的。如果项目中没有任何的办法去管束文件的堆放,那么不出一个星期的开发量,整个项目就会一团糟。因此,我们必须要有某种工具,能够帮助我们检查我们的目录结构,如果发现目录结构有所不对的地方,应该会在 git commits 阶段报错并即时修正。

在我本人的实践中,我会喜欢搭配 pre-commit/pre-commit 以及 Node.js 来帮助我完成这件事情,pre-commit 可以在 git commits 之前运行一段脚本,这些脚本我会放置诸如:

  1. 代码 lint 检查:使用 ESlint/TSlint
  2. 代码 prettier format:使用 prettier
  3. 代码生成规定文档:babylon 解析 AST 并提取注释
  4. 目录规范检查:Node.js 遍历目录

以上四个步骤几乎充满了我的所有正式项目,如果有幸接手我项目的同学,一定能知道,这就是方正的味道

规定如此严格的规范目的就在于「解决人性的懒惰」和「如果我离职,接盘侠能快速上手」,第一个是为了项目能够更好的维护,保持统一的风格,清晰度,第二个就纯粹是职业道德。

着重介绍 src

大部分的项目都使用了 facebook/create-react-app 作为项目的启动模版,着重陈述一下使用 CRA 进行构建后,我们应该如何划分我们的工程目录

pre commits 阶段必须检查的文件目录,没有或者缺失则报错

index.js 自然不用说,属于项目入口的文件,所有的起点都在这里,统一做一些初始化工作,例如加载各种依赖、加载状态管理库等等

router.js 是一个单独的文件,这个文件确定了整个 React 应用的路由表,我会尽量想方设法的把所有的路由都放在这里进行统一的管理,这么做的好处极其明显:统一。(偷偷告诉你们,我会在项目中写一个 eslint 插件对 router 类似的关键词进行检查,如果定义超出了 router.js 的范围,那程序直接报错,无法编译

controller 是一个目录,目录下装着各种各样的控制器文件,这些控制器文件对应到 DVA 和 rematch 之类的状态管理库就是所谓的 model,我个人认为 model 的叫法其实并不合适,而 controller 更为贴切?当然,叫什么随便你,这里不多做撕逼。

assets 公共资源文件。请注意公共二字我特别打上了重点,其原因是很多开发人员将组件级别的资源文件放置到了公共资源文件进行统一的管理,但是在实践中我并不认为这是一个特别好的选择。与组件强依赖的资源文件我认为和组件一起放置在一个文件夹内,能够更快、更容易的进行管理。只有通用的公共文件才会放在这里来。

pages 和 components 文件夹,前者放置的是页面以及页面强依赖的组件,例如注册页面 login,用户管理界面 user 等等。后者则放置的是公共组件。与公共资源文件一样,强依赖的组件就应该和其页面在同一个文件夹中去管理。

component 文件夹比较特殊,里面可能装着 button/select/card 等等组件

除了 index.js 和 __test__ 文件夹之外其他全部自动生成

我们自己写的组件最大的痛点可能就是没有文档,懒得写 proptypes,没有测试,导致的是过一段实践,自己就再也不知道自己到底写了什么,因此,在这方面我也做了强制的规范:

  1. 使用文档构建工具(react docgen 或者自己写 ast )来检查组件目录下是否符合规范。
  2. 使用文档构建工具(react docgen 或者自己写 ast )来生成组件的 index.md 和 index.d.ts 文件
  3. 一般来说,项目中公共组件的测试,至少要达到80%以上,而实际页面逻辑部分测试只需要测试关键点即可。(当然鼓励你到达100%)

单个 JS 文件不应该超过 250 行代码(不包含注释)

这个我知道,会被人拿出来砍死。很多程序员上手随便写写,就会超过 250 行,我这么一规定就会搞死很多人。

然而,对于 React 这种极为细粒度的框架而言,250 行能够做成很多很多的事情,超过 250 行的 js 文件,应该思考如何进行拆分、剔除重复性逻辑。

这个检查,比较因人而异,因此我放在最后说,而在我的项目中,超过 250 行的 js 文件会被检测出来,但只是给予 警告处理,在做 code review 的时候,我会重点看这个文件中的逻辑。

最后进行一个总结

  1. 善于利用 Node.js 的能力,以及各种检查工具,帮助我们强制规范化我们的代码,避免我们人性的懒惰。
  2. 层层递进的项目代码结构划分,使得我们在宏观上对我们的代码有了极大的把控
  3. 再次强调规范化在项目中的作用,虽然一开始觉得复杂,但是项目起来以后维护变得极为轻松。
  4. 个人建议,单个 react 组件文件不宜超过 250 行。
普遍的 react 项目情况
我们希望达到的情况