前言
使用React技术栈管理大型复杂的应用往往要使用Redux来管理应用的状态,然而随着深度使用,Redux也暴露出了一些问题。如编写页面配套(action、reducer)过于繁琐、复杂,组件之间耦合较深、不够扁平化、调用action creator发起动作破坏action纯洁性且必须层层传递等。这些缺点迫使使用Redux的人开始探索好的架构方式,解决或减轻使用Redux的问题。业界标杆阿里为此推出了dva 和 Mirror两种改良Redux的架构方案,不过这两者类似,本文就介绍一下dva。
概述
本文介绍了dva的产生背景,dva是什么,用来做什么,解决了什么问题,使用场景,原理,实践以及我的使用心得。
背景
Redux 文档中介绍,我们需要编写页面的action creator来提交,需要写reducer来更新state,最好对action 和 reducer 做页面为单位的分割,利用redux 给的API 构建容器组件包裹父组件来connect store拿到数据,然后再向下传递给functional component 来渲染,整个过程就实现了单向数据流。当应用复杂起来,一般的做法是配合react-router 做页面分割,光这个分割,你就得 做redux store 的创建,中间件的配置,路由的初始化,Provider 的 store 的绑定,saga 的初始化,还要处理 reducer,component,saga之间的联系...这个没办法,Redux就这么复杂;但是每个页面下要有自己对应的action、reducer,一般还会有saga,这样的话每个页面下都要有四五个文件目录(还有components、containers),每个文件目录下估计还要有不同功能的action、reducer、saga...如果这能忍的话,你在组件里发起action有两个方案,第一:调用经过层层传递的action creator 或者 sagas,第二,让saga监听action,再在组件里直接dispatch相应action类型就行了,不用层层传递,但是得提前 fork -> watcher -> worker.....真的是非常复杂,容易出错。
dva 是什么
dva名字取自游戏守望先锋里的一个驾驶机甲的韩国英雄叫dva,大概含义就是Redux的机甲吧...
确实,
dva 是基于现有应用架构 (redux + react-router + redux-saga 等)的一层轻量封装,没有引入任何新概念,全部代码不到 100 行。( Inspired by elm and choo. )
dva 帮你自动化了Redux 架构一些繁琐的步骤,比如上面所说的redux store 的创建,中间件的配置,路由的初始化等等,没有什么魔法,只是帮你做了redux + react-router + redux-saga 架构的那些恶心、繁琐、容易出错的步骤,只需写几行代码就可以实现上述步骤,它解决了背景所说的所有缺点。dva介绍
此外,dva重要的特性就是把一个路由下的state、reducer、sagas 写到一块了,清晰明了
- app.model({
- namespace: 'products',//分割的路由,对应要combine到root Reducer里的名字,这里就是state.products
- state: { //这个路由下初始state
- list: [],loading: false,},subscriptions: [ //用来监听路径变化,这里就是当路由为products时dispatch一个获取数据的请求
- setup({ dispatch,history }) {
- return history.listen(({ pathname }) => {
- if (pathname === 'products') {
- //dispatch({ type: 'getUserInfo',payload: {} });
- }
- });
- },],effects: { //saga里的effects,里面的各种处理异步操作的saga
- ['products/query']: function*() {
- yield call(delay(800));
- yield put({
- type: 'products/query/success',payload: ['ant-tool','roof'],});
- },reducers: { // reducers
- ['products/query'](state) {
- return { ...state,loading: true,};
- },['products/query/success'](state,{ payload }) {
- return { ...state,list: payload };
- },});
dva的思想
dva就是把之前Redux每个路由下的state、reducer、sagas写到一块去了,做了写到一块去也能做到以前redux能做的事,并且让思路变得很清晰 :
每个路由下都有一个model,这个model掌管这个路由的所有状态(action、state、reducer、sagas),组件想改变状态dispatch type名字就行了。
实践
搞懂框架的脚手架是快速上手这个框架的一个好方法,下面是dva-cli
项目架构
- .
- ├── src
- ├── assets # 图片、logo
- ├── components # 公用UI组件
- ├── index.css # CSS for entry file
- ├── index.html # HTML for entry file
- ├── index.js # 入口文件
- ├── models # 这里存放的就是上面说的dva的model,最好每个路由一个model
- ├── router.js # 路由文件
- ├── routes # 路由组件,跟Redux相同
- ├── services # 每个页面的services,通常是获取后端数据的接口定义
- └── utils # 存放一些工具
- └── request.js # 这里封装一个用来与后端通信的接口
- ├── .editorconfig #
- ├── .eslintrc # Eslint config
- ├── .gitignore #
- ├── .roadhogrc # Roadhog config
- └── package.json #
按照dva的架构,每个路由下都有个model层,在model定义好这个路由的initialstate、reducers、sagas、subscriptions;然后connect组件,当在组件里发起action时,直接dispatch就行了,dva会帮你自动调用sagas/reducers。当发起同步action时,type写成'(namespace)/(reducer)'
dva就帮你调用对应名字的reducer直接更新state,当发起异步action,type就写成'(namespace)/(saga)'
,dva就帮你调用对应名字的saga异步更新state,非常方便:
在组件里:
注意,dispatch用来更新state某个数据后,下一步从state拿到的这个数据并不是更新后的:
此外,由于不用层层传递action creator,mapDispatchToProps
就不用再写了,组件之间的耦合度也降低了,或者说根本没有关系了,dva使组件之间的关系变得更加扁平化,没有什么父子、兄弟关系,这样组件就具有很高的可重用性。所有需要在组件里通信的数据都要放在state中,然后connect组件,只拿到组件关心的数据,就像这样:
- class App extends Component {
- ...
- }
- function mapStateToProps(state) {
- const {
- data
- } = state.user; // user 对应namespace
- const loading = state.loading.effects['user/fetch'];
- return {
- data,loading
- };
- }
- export default connect(mapStateToProps)(User);
这样写,除了具有很高的重用性,也避免了父组件更新,子组件也会随之更新的缺点了!只要这个组件关心的数据没变,它就不会重新渲染,省掉了重写shouldComponentUpdate来提高性能,逻辑也变得清晰、简单起来!
另外,model下有个subscriptions
用于订阅一个数据源,可以在这里面监听路由变化,比如当路由跳转到本页面时,发起请求来获取初始数据:
- subscriptions: {
- setup: ({ history,dispatch }) => history.listen(({ pathname,query }) => {
- if (pathname === '/user') {
- dispatch({
- type: 'fetch',payload: {
- query
- }
- });
- }
- }),};
问题
使用没多久,了解较浅,暂时没发现什么问题
总结
dva框架封装了Redux 架构一些繁琐、复杂的步骤和常用库,使用dva,不会构建Redux架构也可以,dva帮你做好了;
dva 降低了组件之间的耦合度,没有父子、兄弟组件的关系,提高了组件可重用性以及渲染性能,使思路变得简单清晰;
dva架构思路清晰,代码书写方式固定,有利于团队合作,但可扩展性不强