分析阿里前端-自动化架构思路-react

中心思想是基于react的前端自动化开发框架的搭建思路及探索

文章前说明：此文章不涉及教授前端自动化架构搭建，而是细节探讨，

如发现代码刺眼，看完身体不适着，可点赞保留，等掌握自动化开发后再来看这篇文章

先说写题外话，现在前端这个行业，已经从原始时代走进了基于node.js的自动化开发时代。

我们曾经写代码像是反翻垃圾桶，你想要什么插件就需要浪费很多时间去寻找资源，找不到的话只好自己造轮子，或者自己封装一个，就像我曾经就拿着自己的移动硬盘，里面装满了我封装的原生js插件，和一些动画特效例子。

现在是在逛超市，所有的插件，方法组件，ui组件放在货架上，只要你推着购物车，就可以轻易的拿到他们。

现在大势所趋，无论vue、angular、react都已经越来越符合这种组件化开发的模式，说来也不好笑，angular宁可不向前兼容，也要做出这样的改变。

言归正传，这篇文章并不是要跟你们沟通如何构建前端开发框架的，而是对比一些基于react的自动化开发的技术组合，以及一些开发的条理性的分析，细节才是最重要的

因为最近在和阿里开发一个项目，这个项目中的架构搭配，代码结构，语法风格等是我看到过最好的开发方案，可以满足多人开发场景，我说的这个满足是清晰明了，哪怕你这个项目多年后是新人来维护也可以一目了然，虽然其代码清新规范的功劳大多归结于eslint-airbnb,但是其目录结构，备注，整体的数据结构存放，都是很重要的点。

一、分析主角代码

1、首先看看package.json

(注：这是我精简过后的，不可以直接拿到init初始化目录直接生成项目结构)

• cool-cli - 主要负责编译，打包功能你可以换成你喜欢的webpack、roadhog等
• eslint - 代码规范检查工具
• eslint-config-airbnb - 这个就厉害了，这个airbnb是一般人不敢用的代码规范规则，真的很严格，如有希望自己代码风格严肃严谨的自己了解下。
• antd - 不多说 完善的企业级UI框架
• classnames - 为了配合cool内嵌的scss 方便引入样式，也为了防止样式全局污染
• isomorphic-fetch - 封装请求核心
• mobx - 数据管理核心，适合团队开发，方便修改、维护（下面将介绍几种别的数据管理js）
• mobx-react - 同上 有些更贴合react的api
• react-router - 路由核心

上述这些除了 推荐Airbnb之外没什么好说的了
在自动化开发的结构中，上述这些就是车零件，有些零件没了车就跑不了。

2、项目目录结构
虽然项目目录结构这个东西怎么放、怎么嵌套大多纯靠自己的心情，而且一般不会影响什么，因为编译打包配置的时候一个正则就全覆盖了。但是下面这个结构我只能说“欣赏”。

src

asset ：共有静态资源目录

images ： 共有图片

common ：共有js文件目录

utils.js ： 一些共有方法

components ：React组件目录

ant ：对ant的一些基础组件进行封装

common ：共有的业务组件

somePage ：这里是业务模块的开发->业务页面写在这里

config ：配置文件目录

dataConfig.js ：应用一些常量配置

routeConfig.js ： 路由变量配置

model ：存储全局数据模型目录

Store.js ：存储数据，可以剥离出子仓库，mobx仓储

routes ：路由组件目录

index.jsx ：顶层路由入口 Main ： 页面结构

services ：service请求目录

Service ：service请求

styles ：全局样式目录

animation.less ：主题首页，专题首页应用的动画

antd-theme-file.less ： 覆盖ant样式变量定义

index.less ：入口样式文件，引入antd官方提供的 less 样式入口文件

index.scss ：一些全局样式

vars.scss ： 自定义一些样式变量

antdIconfont ：本地ant字体图标

fonts ：本地字体

iconfont ： 本地其他字体图标

index.html ：入口html文件

index.jsx ：入口jsx

.cool.dev.config.js ：覆盖cool开发模式下的一些配置

.cool.prod.config.js ：覆盖cool生产模式下的一些配置

ps: 上述目录结构为删减后精简版本，仅供参考

      上面的层次调理清晰无比，公共方法-数据层-业务配置-组件开发-样式-路由-请求，这些都放在了同一层，我个人认为这样是比较合理的，他们这些的层级很高并且层级应该相同，因为每个模块下面都有可能随着项目的开发扩大，而衍生出很多子模块。如果这些逻辑之间相互嵌套，随着需求的不断变更，结构会越来越混乱，别说你闭眼睛都知道哪个文件在哪，我谈的是拿出去给别人开发，别人看你的项目时候所耗费的时间成本，这种继承性在我看来在前端中很少有人做到。

3、备注的重要性

内部具体的代码由于有eslint-airbnb的规则约束，很严格，所以很美观（主要是我这边不好展示出来），有需要了解的朋友可去开源的airbnb那里看看例子和规则。

备注这方面的话，我举个我平常写的一个参考。

变量的话使用 // 方式来注释

方法的话 /* */ 方式来注释

组件的话用 /** + enter 这种

4、整体逻辑

Mobx 仓 来存放业务公共数据 方法 变量

通过inject注入到组件的props中， 在constructor中转化为本地变量， 事件触发model里的action

@observer监听 被监听者，被监听者变化引发render。

上述内容并不重要，一带而过即可，想学mobx的推荐直接去找中文文档，简单易学

二、分析其他代码

我本想把另一个项目的代码放这里跟上面进行对比，

其实我发现并不用，殊途同归，好代码都是相似的模样，乱的，各有各的乱。

1、package.json 来说，插件搭配不合理，这是一个重病，就像不合脚的鞋，越穿越磨脚。

2、目录嵌套严重，或者剥离太彻底，在很多场景中，比如业务逻辑有条线很长的时候，就会陷入找文件困难的情形， import * from './../../../../../' 或者 import * from 'xx/xx/xx/xx/xx/xx/'等情况。

3、备注方面的话，估计也不用我多说，接盘别人项目的时候如果没有备注或者备注不全面的话，该怎么砸键盘就是个问题了。

4、整体逻辑这一点，如果你写过原生的react + redux模式的话你就会深有体会，所有的数据最开始像织毛衣一样，织成了一件衣服后，频繁的需求会把毛衣打回毛线球。

三、总结

个人观点：

前端这几年的发展可以用百花争艳来修饰，沉寂了太长时间，现在跑上了高速公路，辛苦了各位。

分久必合，这个道理谁都懂，现在大家也应该有了个雏形，至少前端发展目前的稳定版本是组件化自动开发。

共勉。

四、声明

注：上述关于目录、项目结构仅供技术层面沟通交流使用，不掺杂任何业务逻辑，禁止转载，点赞保存即可