uni-app小程序登录后…

前情

最近新接了一个全新项目，是类似商城的小程序项目，我负责从0开始搭建小程序，我选用的技术栈是uni-app技术栈，其中就有一个用户登录功能，小程序部分页面是需要登录才可以查看的，对于未登录的用户需要引导用户去登录页面，再back回来重新渲染当前页面，以让用户正常使用
思考

问题也不复杂，就是判断登录状态而已，需要登录的页面没登录就引导去登录再回来，回来后再重新渲染页面数据即可
这里有二个动作：一个是判断登录态，一个是重新渲染页面数据，有动作就有触发时机，对于判断登录态，我们是在跳转前判断，还是在跳转进需要登录的页面再判断，对于重新渲染数据当然是进入页面的时候再重新渲染，但是怎么去实现重新渲染了，对于小程序我们第一时间想到的是通过生命钩子来做，那当然就是onShow了
解决方案

基于上述的思考，我想到如下二种解决方案：

应该能解决的方案应该有很多，这只是我在实现这个需求的时候想到的二种方案
场景方案1：跳转进需要登录的页面再判断是否是登录态，同时登录回来后通过onShow生命钩子重新渲染页面
此方案优点：就是判断登录态你不需要特定代码去判断，在服务端接口这一块做下处理即可，如果返回状态码是401或者是你和服务端沟通好的错误码时再引导去登录页，这样全局做请求拦截就行，项目中我就是有做这一块的处理，使用的是我封装好的工具方法：常用工具方法 - DCloud 插件市场已分享到插件市场，欢迎使用
此方案的缺点：在未登录的状态下，用户会看到明显的页面跳转，跳转到一个空白页面，突然又跳转到登录页，用户体验不是特别好，同时在onShow生命周期钩子里做数据重新渲染会有一个问题，这样会造成过多的网络请求，如果用户量不小的话会对于服务器造成一些压力
场景方案2：跳转进需要登录的页面前判断登录态，并记录正在跳转的页面，登录后重定向到前面已经记录的跳转页面
此方案优点：避免了onShow频繁触发导致服务器渲染浪费的问题，缺点就是你需要在每一个跳转需要登录的页面前做登录态判断，会导致代码冗余工作量增加，后期维护不是特别好
方案选择

我选择的是场景方案2
二种方案都有优缺点，方案1有一点是用户感受最直接的，就是闪跳的用户体验那一点，至于onShow会导致接口频繁请求问题是有方法解决的，后面会提到；方案2只要想办法解决代码冗余的问题即可
方案实现细节

解决代码冗余问题，我们使用uni-app的拦截api来做下路由拦截即可，根据跳转的URL和当前登录态判断要不要先跳登录页做登录，在main.js中增加路由拦截，关键代码如下：

1. ...
3. /**
4. * 需要登录才能跳转的页面
5. */
6. const needLoginPages = [
7.   '/orders/detail/detail',
8.   '/orders/orderList/orderList',
9.   ...
10. ]
12. // 要拦截的路由方法
13. const interceptors = ['navigateTo', 'reLaunch', 'redirectTo']
14. const globalStoreInstance = globalStore(pinia);
16. // 路由拦截
17. interceptors.forEach(interceptor => {
18.   uni.addInterceptor(interceptor, {
19.     invoke(e) {
20.         // 判断当前页面是否是要需要登录才能跳转的页面里
21.       const needLogin = needLoginPages.findIndex(item => e.url.includes(item)) !== -1;
22.       if (needLogin && !storage.get(TOKEN)) {
23.           // 记录要跳转的页面
24.         globalStoreInstance.setNeedLoginBackPage(e.url);
25.         uni.navigateTo({
26.           url: '/other/login/login'
27.         })
28.         return false
29.       }
30.       return true
31.     }
32.   })
33. })
35. ...

复制代码

我在写这篇博客的时候，我发现这里代码其实有一个可优化点，你发现了吗？欢迎留言
来源：程序园用户自行投稿发布，如果侵权，请联系站长删除
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！