在 React 中处理数据流问题的一些思考

正文

请到「今天看啥」查看全文

null }, action ) => {

switch ( action . type ) {

case FETCH_DATA_START :

...

case FETCH_DATA_SUCCESS :

...

case FETCH_DATA_ERROR :

...

default :

return state

}

}

view . js

import { createStore, applyMiddleware } from 'redux';
import thunk from 'redux-thunk';
import reducer from 'reducer.js';
import { fetchData } from 'actions.js';

const store = createStore(reducer, applyMiddleware(thunk));
store.dispatch(fetchData());

第一个问题，发一个请求，因为需要托管请求的所有状态，所以需要定义很多的 action ，这时很容易会绕晕，就算有人尝试把这些状态再封装抽象，也会充斥着一堆模板代码。有人会挑战说，虽然一开始是比较麻烦，繁琐，但对项目可维护性，扩展性都比较友好，我不太认同这样的说法，目前还算简单，真正业务逻辑复杂的情况下，会显得更恶心，效率低且阅读体验差，相信大家也写过或看过这样的代码，后面自己看回来，需要在 actions 文件搜索一下 action 的名称， reducer 文件查询一下，绕一圈才慢慢看懂。

第二个问题，按照官方推荐使用 redux-thunk 实现异步 action 的方法，只要在 action 里返回一个函数即可，这对有强迫症的人来说，简直受不了， actions 文件显得它很不纯，本来它只是来定义 action ，却竟然要夹杂着数据请求，甚至 UI 上的交互！

我觉得 Redux 设计上没有问题，思路非常简洁，是我非常喜欢的一个库，它提供的数据的流动方式，目前也是得到社区的广泛认可。然而在使用上有它的缺陷，虽然是可以克服，但是它本身难道没有可以优化的地方？

---

---

dva

dva 的出来就是为了解决 redux 的开发体验问题，它首次提出了 model 的概念，很好地把 action 、 reducers 、 state 结合到一个 model 里面。

model . js

export default {
  namespace: 'products',
  state: [],
  reducers: {
    'delete'(state, { payload: id }) {
      return state.filter(item => item.id !== id);
    },
  },
};

它的核心思想就是一个 action 对应一个 reducer ，通过约定，省略了对 action 的定义，默认 reducers 里面的函数名称即为 action 的名称。

在异步 action 的处理上，定义了 effects （副作用） 的概念，与同步 action 区分起来，内部借助了 redux-saga 来实现。

model . js

export default {
  namespace: 'counter',
  state: [],
  reducers: {
  },
  effects: {
    *add(action, { call, put }) {
      

请到「今天看啥」查看全文