uni-app小程序登录后并跳回访问页面

## **前情** 有一个用户登录功能，小程序部分页面是需要登录才可以查看的，对于未登录的用户需要引导用户去登录页面，再back回来重新渲染当前页面，以让用户正常使用 ## 思考 问题也不复杂，就是判断登录状态而已，需要登录的页面没登录就引导去登录再回来，回来后再重新渲染页面数据即可 这里有二个动作：一个是判断登录态，一个是重新渲染页面数据，有动作就有触发时机，对于判断登录态，我们是在跳转前判断，还是在跳转进需要登录的页面再判断，对于重新渲染数据当然是进入页面的时候再重新渲染，但是怎么去实现重新渲染了，对于小程序我们第一时间想到的是通过生命钩子来做，那当然就是onShow了 ### 解决方案 基于上述的思考，我想到如下二种解决方案：  应该能解决的方案应该有很多，这只是我在实现这个需求的时候想到的二种方案 **场景方案1：跳转进需要登录的页面再判断是否是登录态，同时登录回来后通过onShow生命钩子重新渲染页面** 此方案优点：就是判断登录态你不需要特定代码去判断，在服务端接口这一块做下处理即可，如果返回状态码是401或者是你和服务端沟通好的错误码时再引导去登录页，这样全局做请求拦截就行，项目中我就是有做这一块的处理，使用的是我封装好的工具方法：[常用工具方法 - DCloud 插件市场](https://ext.dcloud.net.cn/plugin?id=18675)已分享到插件市场，欢迎使用 此方案的缺点：在未登录的状态下，用户会看到明显的页面跳转，跳转到一个空白页面，突然又跳转到登录页，用户体验不是特别好，同时在onShow生命周期钩子里做数据重新渲染会有一个问题，这样会造成过多的网络请求，如果用户量不小的话会对于服务器造成一些压力 **场景方案2：跳转进需要登录的页面前判断登录态，并记录正在跳转的页面，登录后重定向到前面已经记录的跳转页面** 此方案优点：避免了onShow频繁触发导致服务器渲染浪费的问题，缺点就是你需要在每一个跳转需要登录的页面前做登录态判断，会导致代码冗余工作量增加，后期维护不是特别好 ## 方案选择 我选择的是场景方案2 二种方案都有优缺点，方案1有一点是用户感受最直接的，就是闪跳的用户体验那一点，至于onShow会导致接口频繁请求问题是有方法解决的，后面会提到；方案2只要想办法解决代码冗余的问题即可 ## 方案实现细节 解决代码冗余问题，我们使用uni-app的拦截api来做下路由拦截即可，根据跳转的URL和当前登录态判断要不要先跳登录页做登录，在main.js中增加路由拦截，关键代码如下： ```jsx ... /** * 需要登录才能跳转的页面 */ const needLoginPages = [ '/orders/detail/detail', '/orders/orderList/orderList', ... ] // 要拦截的路由方法 const interceptors = ['navigateTo', 'reLaunch', 'redirectTo'] const globalStoreInstance = globalStore(pinia); // 路由拦截 interceptors.forEach(interceptor => { uni.addInterceptor(interceptor, { invoke(e) { // 判断当前页面是否是要需要登录才能跳转的页面里 const needLogin = needLoginPages.findIndex(item => e.url.includes(item)) !== -1; if (needLogin && !storage.get(TOKEN)) { // 记录要跳转的页面 globalStoreInstance.setNeedLoginBackPage(e.url); uni.navigateTo({ url: '/other/login/login' }) return false } return true } }) }) ... ``` 我在写这篇博客的时候，我发现这里代码其实有一个可优化点，你发现了吗？欢迎留言👀讨论 同时在登录页登录成功后需要做一下跳转逻辑，关键代码如下： ```jsx ... // 解决登录后跳转的问题 if (globalStoreInstance.needLoginBackPage) { uni.redirectTo({ url: globalStoreInstance.needLoginBackPage, complete: () => { globalStoreInstance.setNeedLoginBackPage(''); } }) } else { // 解决登录回去页面数据丢失的问题 const pages = getCurrentPages(); if (pages.length >= 2) { // 获取前一个页面实例 const prevPage = pages[pages.length - 2]; // 调用前一个页面的onLoad方法 if (prevPage?.onLoad) { prevPage.onLoad(prevPage.options || {}); // 传递原始参数 } } uni.navigateBack(); } ... ``` 看代码除了跳转还处理了back，这一段back逻辑也是我在实现的时候发现它可以解决方案1的onShow问题，也就是说方案1也就是只有一个体验问题，所以二种方案我觉得都是可行的，同时我提供方案1接口拦截的代码： ```jsx import { Request, storage } from '@/uni_modules/hbxw-utils/js_sdk/hbxw-utils.js'; import { BASE_URL } from '@/config/http'; import { TOKEN } from '@/config/common'; const request = new Request({ isLogin: true, }); request.baseUrl = BASE_URL; /** * 请求拦截，可以通过add方法添加多个 * 参数为请求配置，可以对请求参数做一些特殊处理 */ request.requestIntercept.add((requestConfig) => { // 如果有传就用传的，没有就去取，为了解决登录默认token console.log('---- requestConfig ----:', requestConfig) if (!requestConfig.header) { requestConfig.header = {} } // 如果header中没有Accept，则设置为application/json if (!requestConfig.header?.Accept) { requestConfig.header.Accept = 'application/json'; } if (!requestConfig.header?.Authorization) { let Authorization = '' try { Authorization = storage.get(TOKEN) || ''; } catch (err) { console.log(err) } // 添加Authorization到header中用于服务端登录判断 if (Authorization) { if (!requestConfig.header) { requestConfig.header = {} } requestConfig.header.Authorization = Authorization; } } // 如果返回true则请求会中断 // return true; }); /** * 响应拦截，可以通过add方法添加多个 * 第一个参数为请求响应体 * 第二个参数为请求配置信息 */ request.responIntercept.add((response, requestConfig) => { console.log('---- response ----:', response) // 如果接状态码为401，而且当前接口是需要判断登录状态的 if (response.statusCode == 401 && requestConfig.isLogin) { uni.navigateTo({ url: '/other/login/login' }) // 返回true 中断后面处理 return true; } // 通用错误处理 if (response.statusCode !== 200 || response.data.code !== 200) { uni.showToast({ title: response.data.message || '请求失败，请稍后再试', icon: 'none' }) return true; } }); export default request; ``` ### 期望 解决问题的方法千千万，上述是我是解决登录跳转逻辑的处理方案，如果在上面二种方案中，你会选择哪一种了？聪明的你也一定有别的更好的方案，期待你的分享和留言👀，共同进步。