React进阶（六）如何组织代码结构

就只看标题的同学肯定会心有疑虑了，废话了那么多，怎么还不开始讲解React相关的知识。其实从最开始我就已经说明了，React相关的基础知识并不是什么很难的知识点，他们一点也不神秘，掌握他们很容易。而真正的精髓，是React想要向大家传递的开发思维。如果你抱着只是学习知识点的心态来读这些文章，那么很抱歉，你可能会很失望。因为对于知识点的讲解，没有比文档更全的了。

阅读过上一章的内容，想必大家也能感受到，如果要将这系列所有文章中的案例集成在一个项目里面，那么这个项目必然不会简单，它最终的样子也不会是普通demo的模样。因为需求更高，因此一定会更加贴近实践项目。所以在开发过程中，就会不断的按照需求往构建工具迭代更多的能力。因此我们就要在项目开始的时候，一定要组织好一个扩展性相对更高的代码结构，否则到最后无论怎么调整都满足不了需求，就只有面临重构。那样所需要花费的成本就很高。

在组织代码之前，我们通常会按照如下的标准（宽泛一点）来定义一个人写的代码是否优秀

• 可读性

JS作为一门弱类型的高级语言，代码的写法就会有很大的差别，10个人也许大家各自都有不同的风格，这也会导致如果没有一个合理的规范，那么写出来的代码可读性就会很低。在一个团队中，往往会力求大家的代码风格尽量保持一致，这样阅读其他人的代码就会更加轻松。这也要求了我们要尽量避免使用生僻的黑科技（特殊场景除外）

• 可扩展性

我们要尽可能的预想到未来会出现的需求与问题，让代码能够在需求增加的情况下能够无痛叠加。当然我们并不能100%的预想未来会出现什么情况，有这样的思考，我们就可以让重构来的更晚一点。当你的代码实在无法满足新的需求时，我们也要随时最好重构代码的心理准备，哪里会付出很大的代价。

• 可维护性

当代码出现问题时，我们期望能够更快的修复bug。那么代码的可维护性越高，往往就更能够帮助你提高工作效率。

当然，如果没有丰富的实践经验做支撑，也许你还没办法一步到位做到很好，不过我们在每一次的实践中都依次来要求自己，那么进步一定是能够感受得到的。无论是模块化还是组件化，其实都是为了让代码更加具有上诉的优势。

那么，在这样的思考下，我们可以怎么组织代码呢？

1. 功能模块都放在根目录下的src目录里

通常情况下，项目根目录都会放一些配置性的文件，未来我们可能涉及到的配置文件会逐渐变多，例如

• .gitignore git忽略的文件或者文件夹的配置
• package.json 项目依赖包等的配置
• .babelrc bael配置
• .eslintrc eslint配置
• more...

因此我们会将更多的业务逻辑代码等都放在一个统一的目录（src）下以区分开来。

2. 功能模块放在统一的目录里 src/utils

在一个项目中，我们一定会无法避免的使用许多的工具方法，例如从URL中获取参数，向服务器请求数据等等。通常情况下我们会把这些功能模块按照不同的功能统一放置在utils目录里。

+ src
  + utils
    - http.js
    - index.js
    - map.js
    - share.js

那么我们在引入时就可以第一时间想到这个模块在utils目录里，例如map模块中有一个获取当前地址的工具方法

import { getLocation } from '../../utils/map';

3. 自定义的公共组件放在src/components目录里

虽然整个项目在上一章中我们从单页应用配置改换成为了多页应用配置。但是仍然会有许多的公共组件在每一个页面都可能会被用到。例如图标组件Icon，按钮组件Button等。因此我们需要一个统一的目录来管理这些公共组件，如果实践足够丰富，慢慢的就会形成自己的一个组件库。

+ src
  + components
    - Icon
    - Button
    - Toast
    - ...

4. 每一个应用都会有各自的页面组件，统一存放在src/pages中。

多页面应用前端架构比单页面应用更为复杂，也就导致了组件管理就会更加复杂一些。pages目录下会分别存放各自页面的页面组件，一个单页里还有有更多的子页面。页面组件的名字与public中的html文件保持一致。

+ src
  + pages
    + RA5_02
      + ModuleA
      + ModuleB
   + RA7_01
      + ModuleA
      + ModuleB

5. 统一管理接口调用方法，从业务逻辑中拆分成独立的模块，存放在src/services里

+ src
  + services
    - a.js
    - b.js
    - c.js
    - d.js

当然，当项目越来越复杂，还需要将services中的模块分类。

6. 当我们引入redux/mobx时，还需要做更多的处理，后续涉及到了我们再细说

模块管理方式并不唯一，我们还可以有别的尝试

7. 设置别名

当我们试图通过相对路径引入模块时，如果当前模块的目录层级比较深，那么路径就会很难受。我们不但要小心翼翼的确保相对路径的正确性，还会导致模块在项目中的迁移成本增加。如下：

import { getLocation } from '../../../utils/map';
import { Icon } from '../../../components/Icon';
import { Button } from '../../../components/Button';

确实很难受，因此我们需要在构建工具中设置对应目录的别名，让我们在项目中引入模块时这样写

import { getLocation } from 'utils/map';
import { Icon } from 'components/Icon';
import { Button } from 'components/Button';

构建工具会自动帮助我们寻找到对应的模块，那么我们需要做的是调整构建工具，在config/paths.js中，调整代码如下：

// 别名
const alias = {
  components: resolveApp('src/components'),
  pages: resolveApp('src/pages'),
  utils: resolveApp('src/utils'),
}