We read every piece of feedback, and take your input very seriously.
To see all available qualifiers, see our documentation.
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
背景:当接口报一些没权限的错误时,如何处理这个问题?
有一个错误页面统一处理错误:ErrorPage。 api返回成功后,判断errno,如果是NO_AUTH,跳转到错误页面,加上query。type=no-auth。
ErrorPage
缺点:这个方案,看起来没有问题,但是也有很多问题。下面列出几个: 对于小程序来说
backUrl=xxxxxxxx
backUrl=scanCode
因此,当错误多的时候,显然ErrorPage上的路由协议是难以维护的。同时ErrorPage里面的业务逻辑也是难以维护的。
总结:这个方案,可以临时使用,快速上线,但是显然,维护成本比较高。
这个方案分两个步骤:一个是接口出错时候的throw Promise.reject(注意,这个是Promise,不能是throw Error, 原因是Suspense,本身fallback出发,需要底层throw Promise.reject)。二个是为Suspense添加不同的fallback UI。
这个能解决的问题:我们将fallback的处理,分到了各个页面上,将
The text was updated successfully, but these errors were encountered:
No branches or pull requests
如何抽象出这种类似的错误页面????
背景:当接口报一些没权限的错误时,如何处理这个问题?
方案一:在api层处理
有一个错误页面统一处理错误:
ErrorPage
。api返回成功后,判断errno,如果是NO_AUTH,跳转到错误页面,加上query。type=no-auth。
缺点:这个方案,看起来没有问题,但是也有很多问题。下面列出几个:
对于小程序来说
ErrorPage
需要记录上一页的路径,才能实现。因此,需要加页面加一个协议:backUrl=xxxxxxxx
,ErrorPage
需要加上一个协议backUrl=scanCode
,然后加上扫码逻辑。这个时候,问题又来了,扫码跳转到哪呢。因此,当错误多的时候,显然
ErrorPage
上的路由协议是难以维护的。同时ErrorPage
里面的业务逻辑也是难以维护的。总结:这个方案,可以临时使用,快速上线,但是显然,维护成本比较高。
方案二:利用Suspense,接口报错的时候,往上抛异常(Promise.reject)。
这个方案分两个步骤:一个是接口出错时候的throw Promise.reject(注意,这个是Promise,不能是throw Error, 原因是Suspense,本身fallback出发,需要底层throw Promise.reject)。二个是为Suspense添加不同的fallback UI。
这个能解决的问题:我们将fallback的处理,分到了各个页面上,将
The text was updated successfully, but these errors were encountered: