ant-design-pro使用总结
前言
从上篇博客到现在转眼已经过去了半年，从今天开始博客算是重新捡起来了。从去年12月份开始就写毕设，写毕设的开始也是学习React的开始，后来毕设项目决定使用蚂蚁金服的ant-design-pro框架，毕竟也是刚开始学习React，刚从github拉下来有点懵，不明白那么多模块之间是如何调用的，数据如何和页面关联，伴随着这些疑问去学习了Redux，然后使用Redux写了个TodoList的小Demo，之后就觉得思路清晰多了，明白了整个项目内部的调用流程后，里面的模块就可以随意添加调整，所以个人觉得在使用ant-design-pro之前，最好去学习一下Redux，这样整个思路都会清晰起来。扯皮的话不多说了，直接步入正题。
ant-design-pro的整个框架结构
├── mock # 本地模拟数据
├── public # 存放公共资源
├── src
│ ├── assets # 本地静态资源
│ ├── common # 导航信息和路由的配置
│ ├── components # 通用组件的封装，如表格、表单
│ ├── e2e # 集成测试用例
│ ├── layouts # 通用布局，整个网站的共用导航栏，页脚和主体部分
│ ├── models # dva model
│ ├── routes # 浏览器中所看到的页面
│ ├── services # 后台接口服务
│ ├── utils # 工具库
│ ├── g2.js # 可视化图形配置
│ ├── theme.js # 主题配置
│ ├── index.ejs # HTML 入口模板，相当于index.html
│ ├── index.js # 应用入口
│ ├── index.less # 全局样式
│ └── router.js # 路由入口
├── tests # 测试工具
├── README.md
└── package.json在以上的目录中，所独立出来的模块，对于第一次使用这个架构的同学来说，比较新奇的就是mock模块，以及src中的分层结构：models、service、routes这三部分和common了，下面的内容就重点介绍这三部分的关系，以及每部分的职责。
commom
目前毕设项目所使用的是v1.3.0这个版本，每个版本可能都会有些不同之处，这个版本中目前将导航和路由分开，分别在menu.js和router.js这两个文件中。
- menu.js
主要设置导航栏的信息，如跳转链接和所显示的文字和图标。如下所示：
{
name: '题库', //导航栏上显示的文字
icon: 'table', //显示的图标
path: 'problem', //跳转的链接
}- router.js
这个文件很重要，里面涉及了路由，数据还有页面，主要将路由和页面关联，以及将数据和页面关联。如下所示：
'/problem': {
component: dynamicWrapper(app, ['problemList'], () => import('../routes/ProblemList')
),
},
'/problem/detail/:id': {
component: dynamicWrapper(app, ['problem', 'user'], () => import('../routes/Problem')),
},从上面代码可以看出，一个页面可以关联多个数据，这个根据页面的需求来决定，只要是关联的数据都可以在页面中拿到。dynamicWrapper 函数所做的工作就是将页面与model关联起来，其中第二个参数就是model的文件名。
models
在第二部分框架的基本结构中就说了models是属于dva的，所以如果你之前就使用过dva的话，那这个框架就用起来非常得心应手，model是dva的核心部分，ant-design-pro就是针对dva的一次最佳实践。下面看下model文件的主要结构：
import { getProblemInfo } from '../services/api';
export default {
namespace: 'problem',
state: {
problemInfo: {}, // 题目详情
loading: true,
},
effects: {
*fetchProblemInfo({ payload }, { call, put }) {
yield put({ //开启页面加载动画
type: 'changeLoading',
payload: true,
});
const response = yield call(getProblemInfo, payload); // 获取页面数据
if (response.code === 0) {
yield put({ //将数据交给reducer处理
type: 'saveProblemInfo',
payload: response.data,
});
}
}
}
yield put({ //结束页面加载动画
type: 'changeLoading',
payload: false,
});
},
},
reducers: {
saveProblemInfo(state, action) {
return {
...state,
problemInfo: action.payload, //将数据返回给页面
};
},
changeLoading(state, action) {
return {
...state,
loading: action.payload,
};
},
},
};
- namespace：该字段就相当于model的索引，根据该命名空间就可以找到页面对应的model;
- effects： 处理所有的异步逻辑，将返回结果以Action的形式交给reducer处理；
- reducers：处理所有的同步逻辑，将数据返回给页面；
补充：在effects中调用了service中所封装的后台接口，该调用方式是ES6中的generator函数，该函数使得异步操作如同同步操作一样。call就相当于一个执行器，在call内部对generator函数进行了处理。
routes
在routes中主要涉及两个操作，第一个就是如何拿到数据，第二个就是如何发送同步或异步请求来更新页面数据。
- 如何拿到数据
在该模块中，就是每个路由所对应的页面，下面主要了解数据是如何在页面中取到的：
import { connect } from 'dva';
@connect(state => ({
problem: state.problem,
user: state.user,
}))
export default class Problem extends PureComponent {
render() {
const { problem, user } = this.props;
return (
<div title="题目">{problem.title}</div>
);
}
}从上面的代码可以看到在页面中导入了dva框架，用dva的connect方法可以拿到所有的state，我们只需要在页面中获取需要的state即可。拿到之后所有的数据都是以props的形式嵌入页面的，也就是我们就像操作props来对待这些数据即可。
- 如何更新页面数据
在和model关联的页面中，都会给页面传入dispatch() 这个方法，该方法就是分发的意思，可以发出一个Action，Action是Redux中的概念，发出这个Action后就会找到页面所对应的model，然后做出相应的处理。如下：
componentDidMount() {
const { dispatch } = this.props;
dispatch({
type: 'problem/fetchProblemInfo',
payload: {
id: this.props.match.params.id,
}，
});
}
dispatch中的参数就是一个Action。第一个type字段由两部分组成，前半部分是model的namespace（命名空间），后半部分是该Action的处理位置，对应model中的effects（处理异步逻辑）,或reducers（处理同步逻辑）。
services
这个模块中的逻辑相对比较简单，就是模仿一下后台接口的实现，对请求进行了进一步的封装。
// 获得题目信息
export async function getProblemInfo(params) {
return request(`/apiv1/problem/get?${stringify(params)}`);
}
// 普通提交
export async function commonSubmit (params) {
return request('/authv1/submit/common', {
method: 'POST',
body: params,
})
}
在该层将request的结果返回给model层，放在async内部的函数都是同步的。
Mock
Mock的功能就是可以在本地模拟后台的行为，在框架中主要涉及到.roadhogrc.mock.js文件。如果开启代理的话，当发起请求时就会被代理到本地来处理，根据请求方式和URL就可以返回不同的数据。
总结
以上是对ant-design-pro的一次实践总结，希望有助于刚开始接触这个框架的新手加深理解，具体的时间项目已传至github，欢迎一起讨论。
最后再说一点吧！框架这样的封装，使得页面、后台请求和数据处理逻辑分离，让前端开发和后台开发一样更加工程化，在开发时更容易定位错误，也有利于代码后期的维护。但这使得代码完全依赖于dva框架，如果有天dva停止了维护更新，出现错误无法处理，太依赖第三方库不是很利于项目版本的更新迭代。有利也有弊，所以我们在选择框架时也是要慎重考虑的。