对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而言,我们需要在前端维护整个应用状态,我们需要控制每个数据请求对整个应用状态产生的影响。那么对我而言,我能想到的是两个:可取消,可缓存。 可能由于是从 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页切换,由于快速的相互切换会产生很多请求,不过对于我的业务而言,这『快速切换』的期间,其实不会有什么更新,所以不用频繁发请求,直接拿缓存即可。这里不涉及什么 首先先对于原先的请求,需要简单的包上一层,大致是这样的: if (cached) { return Promise.resolve(fromCache) } else { return PromiseCreator(args).then((result) => { putToCache(result,timeout) return result }) } 不贴完整代码了,大家应该可以脑补出来的。最后我叫这个新的请求方法为 const cachableGet = cachableRequest(request.get,500) cachableGet(url).then(...) 接下来就是要把这个部分和Redux融合起来了,我用的中间件是 { 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,接下来只需要等待 所以我现在放弃使用 { type: LOAD_TASK,onPromised: cacheRequest } 只有一次dispath,也不需要维护3个actionType了,舒服很多。 说实话 它的例子是用ES7的 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,不想再合太多代码进去,现有的解决方案也足够,现在就先没有用,之后再说。 恩,没有了。 (编辑:李大同) 【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容! |