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

·  阅读 2743
分析阿里前端-自动化架构思路-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模式的话你就会深有体会,所有的数据最开始像织毛衣一样,织成了一件衣服后,频繁的需求会把毛衣打回毛线球。

三、总结

个人观点:

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

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

共勉。

四、声明

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

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