为什么越来越多的人选择使用dva:

可能大家通过一点时间的学习，已经能够理解 redux 的概念，并认可这种数据流的控制可以让应用更可控，以及让逻辑更清晰。

但随之而来通常会有这样的疑问：概念太多，并且 reducer,  action 都是分离的（分文件）。

这带来的问题是：

• 编辑成本高，需要在 reducer,  action 之间来回切换

• 不便于组织业务模型 (或者叫 domain model) 。

而 dva 正是用于解决这些问题！

Diav介绍：

dva 是基于现有应用架构 (redux + react-router + redux-saga 等)的一层轻量封装，没有引入任何新概念，全部代码不到 100 行。( Inspired by elm and choo. )

dva 是 framework，不是 library，类似 emberjs，会很明确地告诉你每个部件应该怎么写，这对于团队而言，会更可控。另外，除了 react 和 react-dom 是 peerDependencies 以外，dva 封装了所有其他依赖。

dva 实现上尽量不创建新语法，而是用依赖库本身的语法，比如 router 的定义还是用 react-router 的 JSX 语法的方式(dynamic config 是性能的考虑层面，之后会支持)。

他最核心的是提供了 app.model 方法，用于把 reducer, initialState, action, saga 封装到一起，比如：

app.model({
  namespace: ‘products‘,
  state: {
    list: [],
    loading: false,
  },
  subscriptions: [    
    function(dispatch) {      
      dispatch({type: ‘products/query‘});
    },
  ],
  effects: {
    [‘products/query‘]: function*() {      
        yield call(delay(800));      
        yield put({
        type: ‘products/query/success‘,
        payload: [‘ant-tool‘, ‘roof‘],
      });
    },
  },
  reducers: {
    [‘products/query‘](state) {      
        return { ...state, loading: true, };
    },
    [‘products/query/success‘](state, { payload }) {      
        return { ...state, loading: false, list: payload };
    },
  },
});

在有 dva 之前，我们通常会创建 sagas/products.js, reducers/products.js 和 actions/products.js，然后在这些文件之间来回切换。

介绍下这些 model 的 key ：(假设你已经熟悉了 redux, redux-saga 这一套应用架构)

• namespace - 对应 reducer 在 combine 到 rootReducer 时的 key 值

• state - 对应 reducer 的 initialState

• subscription - elm@0.17 的新概念，在 dom ready 后执行，这里不展开解释，详见：A Farewell to FRP

• effects - 对应 saga，并简化了使用

• reducers

React之dva