场景:
在一个页面中 ,有多个fetch 请求 ,每次请求都会带上tocken ,如果token 验证过期或失败 ,返回登录页。
问题:
如果又多个fetch 请求 ,那么都结束后就会多次返回登录页,怎么避免这种情况? (同步请求是可以解决,但是async await 多少会有点影响整体速度)
场景:
在一个页面中 ,有多个fetch 请求 ,每次请求都会带上tocken ,如果token 验证过期或失败 ,返回登录页。
问题:
如果又多个fetch 请求 ,那么都结束后就会多次返回登录页,怎么避免这种情况? (同步请求是可以解决,但是async await 多少会有点影响整体速度)
我猜你这个场景应该是客户端路由加上页面上多个组件自己发起fetch吧?
建议封装fetch功能为公共对象,各个组件统一调用,对于身份异常可以统一处理,这样当第二个异常要跳转时很好处理了。最简单办法你可以设置一个标志,第一个跳了置true,后面的看到了就不要跳。然后身份处理好了标志置false。
13 回答13k 阅读
8 回答2.8k 阅读
2 回答5.2k 阅读✓ 已解决
5 回答1.4k 阅读
3 回答2.3k 阅读✓ 已解决
3 回答978 阅读✓ 已解决
5 回答1.6k 阅读✓ 已解决
我的方案是用高阶组件+redux解决问题。
首先所有的接口都走redux,数据正常该dispatch哪去dispatch哪去。如果登录失败 dispatch 一个登录失败的action,然后在高阶组件中处理登录问题,如果找不到登录态,那么就跳转登录页,如果有登录态就什么都不做。
注意:不要在reducer中dispatch,登录页本身不要被高阶组件包裹
然后就是审美问题了 withRouter(connect(state=>state)(LoginHOC(YourBusiness)));
就是长了一点而已嘛。。。
其实我也就是随便一答,redux管理接口,确实能做到页面视图完全解藕,但是你们知道接口异常打一个toast有多麻烦。先dispatch到redux,过几秒钟还要在dispatch一个cancelToast
我也在等待更好的接口管理方式。有时挺矛盾的 复用行就以为这解藕,引入了三方状态和subscription,然后再map到自己的状态,解了藕肯定会造成不方便。
ps: 一些脑回路轻奇的同事,让ajax模块接受一个this,然后就能操作页面了,我勒个去。。。那还不如Vue的mixin思想。