Skip to content
This repository has been archived by the owner on Jan 19, 2023. It is now read-only.

[疑难问题]:关于重登录后再次请求失败接口的问题 #8

Open
ACERY1 opened this issue Feb 26, 2018 · 0 comments
Open
Labels
help wanted Extra attention is needed

Comments

@ACERY1
Copy link
Member

ACERY1 commented Feb 26, 2018

[now state]: make it run

需求是:

jwt的设计是如果上一次请求距离这一次请求的时间大于5分钟就视为过期,过期返回http状态码是403,而产品那边的需求是永久不退出登录。那么解决办法是让用户无感知进行登录。

问题:

所以我就单独写了一个Relogin方法,但是Relogin之后无法再次去请求之前那个失败了的接口,即时能请求,也无法执行我在业务层写的回调。因为这涉及到一个“底层模块向高层模块通信”的问题。我在底层模块里进行的Relogin(原理是捕捉403)但是此时底层模块不具有高层模块的细节,所以无法执行高层模块的回调。

预选方案1:请求探针

我想了一下,如果要使用高层模块的回调,那么通过事件触发的请求就是一个完整的流程而不可新添加流程,那么设计一个探针请求,让每个接口都继承一下,每次接口发送请求的时候就先发探针请求,如果成功,流程便继续往下,如果失败就Relogin然后继续往下。这样设计的坏处是有无必要的消耗,因为登录失效而Relogin是小概率事件,对一个小概率事件而去给全局增添一个触发方法太浪费了。

采用方案2:函数递归

我把代码通过Promise进行了封装,使得回调的出口只有resolve,那么这就作为递归的基线条件。递归条件是当该次请求为403时,则进行Relogin并拿到上次请求的config再次调用该函数。

代码实现包含:

  1. /src/API/ajax.js 27~30 行
  2. /src/API/statusCodeFilter.js的forbidden函数
  3. /src/API/Relogin.js的lastAPI函数执行

收获:

巧用Promise的resolve作为出口可以构建唯一过程执行流程,混合callback使用更能将出口深入到其他函数去。基于此可以用来进行过程抽象,控制条件执行分支等。

@ACERY1 ACERY1 added the help wanted Extra attention is needed label Feb 26, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
help wanted Extra attention is needed
Projects
None yet
Development

No branches or pull requests

1 participant