对Redux实践中数据请求的一些想法

作者: leozdgao | 来源:发表于2015-10-24 15:11 被阅读5407次

对Redux实践中数据请求的一些想法
解决拖拽slider时数据更新导致的slider不受控的问题
性能优化
从零创建React项目
手拉手学React：Redux
23. redux
redux 异步action
Redux中间件
React解惑之 redux-saga
从表象理解Redux

也可以在这里看：http://leozdgao.me/reduxshi-jian-zhong-de-xie-xiang-fa/

最近工作之余在写一个SPA的项目，用React+Redux做一个团队协作系统，面向目前的这个项目组的。

这篇文章更像是一篇随笔，比较随性一点，更深入的总结，以及项目演示什么的，以后完成了项目了再来写。

下面基本没怎么贴代码，如果对这个项目有兴趣的话，Github地址如下：https://github.com/leozdgao/chatbox

回到正题，之前自己一个玩具项目里遇到过一个坑，没填上，就是tag切换的时候，获取对应tag的数据，在前一个请求没有完成的情况下快速切换tag，又一个请求出去了，这两个请求可能发生竞争，导致页面上呈现错误的数据。

不同于Server端MVC架构的Web应用来说，对于SPA而言，我们需要在前端维护整个应用状态，我们需要控制每个数据请求对整个应用状态产生的影响。那么对我而言，我能想到的是两个：可取消，可缓存。

可能由于是从node.js开始才正式接触js的关系我个人比较喜欢用Promise，我自己用Promise封装了ajax请求，不过Promise是不能中途取消的（至少标准里的Promise不包含这个功能），于是我做了如下处理，解决了这个问题：

function request (opts) {
  const xhr = new XMLHttpRequest()
  const innerPromise = new Promise((resolve, reject) => {
    ...
  })
  
  return {
    abort: xhr.abort.bind(xhr)
    then: innerPromise.then.bind(innerPromise),
    catch: innerPromise.catch.bind(innerPromise)
  }
}

恩，目前大多数检查Promise对象的方法一是看是不是一个对象，然后有没有一个then的属性且是一个函数，我返回的对象满足这个条件，目前用下来没有什么大问题。

然后是可缓存的问题，还是上面那个例子，两个tag页切换，由于快速的相互切换会产生很多请求，不过对于我的业务而言，这『快速切换』的期间，其实不会有什么更新，所以不用频繁发请求，直接拿缓存即可。这里不涉及什么LocalStorage，对于32位下的v8而言堆内存也有0.7GB，在前端应该不用担心不够用的问题。

首先先对于原先的请求，需要简单的包上一层，大致是这样的：

if (cached) {
  return Promise.resolve(fromCache)
}
else {
  return PromiseCreator(args).then((result) => {
    putToCache(result, timeout)
    return result
  })
}

不贴完整代码了，大家应该可以脑补出来的。最后我叫这个新的请求方法为cachableRequest，可以这样用：

const cachableGet = cachableRequest(request.get, 500)
cachableGet(url).then(...)

接下来就是要把这个部分和Redux融合起来了，我用的中间件是react-promise-middleware，我基于它简单修改了下，主要是为了可以加上timeout的选项，而且请求也不是每次都发，于是action是这样的：

{
  type: YOUR_ACTION_TYPE,
  cachable: true,
  payload: {
    promiseCreator: request.get,
    args: [ url ]
  },
  timeout: 5000
}

大家脑补下这个中间件的实现或者去仓库里看实现，这里不多贴了。

可缓存这一点已经融合进Redux里了，然后其实可取消这一点还没有融合进去，我是用回调的方式来解决这个问题的，就是promiseCreator调用完成后调用一个onPromise，第一个参数就是刚被创建的promise对象，通过这个机会把promise存起来，在合适的时候调用abort()即可：

const cacheRequest = (p) => requests.push(p)

export function load () {
  return {
    types: [ LOAD_TASK_PENDING, LOAD_TASK_FETCHED, LOAD_TASK_FAILED ],
    cacheable: true,
    payload: {
      promiseCreator: request.get,
      args: [ TASK_LOAD_API_URL ]
    },
    timeout: 5000,
    onPromised: cacheRequest
  }
}

export function dispose () {
  requests.forEach(r => r.abort())
  requests = []
}

我额外创建了一个dispose用来在合适的时候取消请求，现在粒度可能比较大，之后再打磨吧，思路基本就这样。

还想写一点，就是几乎每次异步请求我都要写3个action types，而且会dispatch两次，这其实是很不爽的。

常见的case是这样的，一个load的异步请求，组件内维护一个loading的state，请求调用后loading为true，接下来只需要等待componentWillRecieveProps调用，拿到请求完的数据再把loading设为false即可。

所以我现在放弃使用react-promise-middleware了，也将我上面的那个中间件修改了下，不再dispatch那个pending的action，真的感觉没必要，其实也不用针对请求是否成功来区分actionType，只要给action多加个error属性是否为true即可，于是乎现在action是这样的：

{
    type: LOAD_TASK,
    cacheable: true,
    payload: {
      promiseCreator: request.get,
      args: [ TASK_LOAD_API_URL ]
    },
    timeout: 5000,
    onPromised: cacheRequest
}

只有一次dispath，也不需要维护3个actionType了，舒服很多。

说实话redux-promise这个中间件我是知道的，这个库想吐槽下，例子感觉不是特别友好，一开始没有用。现在理解这个库的设计思想了，回过头来简单谈下。

它的例子是用ES7的async function，这里不多谈这个新功能，我自己对这个功能也只是用用，研究不深入。我按它的例子写了如下代码：

async function getResource () {
  try {
    return await request.get(RESOURCE_LOAD_API_URL)
  }
  catch (e) {
    return e
  }
}

// action for load task
export function load () {
  const action = {
    type: LOAD_RESOURCE,
    payload: getResource()
  }

  console.log(action.payload) // Promise

  return action
}

其实这样写是挺好的，不过需要regenerator runtime的polyfill，不想再合太多代码进去，现有的解决方案也足够，现在就先没有用，之后再说。

恩，没有了。