继续浏览精彩内容
慕课网APP
程序员的梦工厂
打开
继续
感谢您的支持,我会继续努力的
赞赏金额会直接到老师账户
将二维码发送给自己后长按识别
微信支付
支付宝支付

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

ITMISS
关注TA
已关注
手记 347
粉丝 51
获赞 244

最近工作之余在写一个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 taskexport function load () {  const action = {    type: LOAD_RESOURCE,    payload: getResource()
  }  console.log(action.payload) // Promise

  return action
}

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

恩,没有了。



作者:leozdgao
链接:https://www.jianshu.com/p/8e3a32129641


打开App,阅读手记
0人推荐
发表评论
随时随地看视频慕课网APP