前端React项目结构及一些约定

发表于 更新于 本文字数： 1.4k 阅读时长 ≈ 2 分钟
本文介绍关于前端React项目结构及一些约定，包括使用场景、实现细节等，以提高关于前端React项目结构及一些约定的效率。

玩React也一年有余，对React的实践有了些许体会。最近在做新项目的前端架构，反思了下之前项目上的不足和问题，决定在这次的结构上改良和精简。
同时，也谷歌了下成熟的设计及一些开源项目，最终决定采取下面的结构。

欢迎讨论碰撞，共同提高。

目录规划

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
├── app
│   ├── action-types          
│   ├── actions
│   ├── api
│   ├── app.less
│   ├── app.tsx
│   ├── components
│   ├── config
│   ├── effects
│   ├── index.tsx
│   ├── reducers
│   ├── routes.tsx
│   ├── shared
│   ├── types
│   └── typings.d.ts
├── webpack
├── favicon.ico
├── i18n
├── index.html
├── manifest.webapp
├── mock-data
├── robots.txt
├── test
├── static
│   └── images
├── .editorconfig
├── .huskyrc
├── .prettierrc
├── tsconfig.json                 
├── tsconfig.test.json
├── tslint.json         
├── yarn.lock

结构下的思考

上面的结构，可能是空洞无谓和简单的，但其背后是我目前的一些思考。这里highlight下。

  1. React是个类库，本身并不是个框架，so，它很灵活。这就是它的魅力所在，因为你怎么玩都行。但项目毕竟不一定是个人项目，我们有时需要去划定框框，这样才能保证项目的组织结构不那么混乱。所以基本的架子即约定确实需要。
  2. 因为React本身不是框架，所以官方并不会有什么建议及要求结构之说。我们具体做项目，需要根据采用的技术栈及实际的业务开发场景，来敲定一个合理的架构。
  3. 我参与的项目使用到了Redux，众所周知，官方提倡我们拆分组件为Components,Containers，即展示型组件，容器型组件。针对这种理念，我觉得对。但在实际的实践中，我发现其实这种分法，会一定程度导致本来强相关的代码被硬生生的分开。so在这次的架构中，我并不打算将其文件夹拆开，无论如何，他们毕竟还是react组件，so直接都在components文件夹下即可。置于内部去分离是否连Redux，那随意了。
  4. editorConfig+tslint+husky对代码的基本风格和质量保驾护航

*备注:*没有最好，只有更好。在接下来的实践中，我也会根据实际情况和发现的问题，对此继续进行改良。欢迎道友提意见

一些约定

除了上面的基本结构之外，我对Team定下了以下约定。

  • 文件夹小写，中线命名法，比如 user-comment
  • 组件文件类名小写中线命名
  • 路由级组件命名增加page后缀

写在最后

18年及以前一直玩的是Angular，最近一年因为项目需要才开始玩React，虽然语法上会有不同，并且一个是类库，一个是框架。好吧，承认，确实有很多的不同，一开始我还会有些不适应。但是当一点点的深入后，其实总会有很多似曾相识的点，比如hook，比如组件通讯、比如路由，等等。直到有一天，恍然大悟，是啊，万法归一。

学技术学的是思想，学的是内容。不要被外表的那些花招所骗。与君共勉。