也可以在这里看: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,不想再合太多代码进去,现有的解决方案也足够,现在就先没有用,之后再说。
恩,没有了。
网友评论
请教下,好像你的登录页和app页是分开的,只是app是单页应用?