uni-app小程序登录后…

前情

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

思考

问题也不复杂，就是判断登录状态而已，需要登录的页面没登录就引导去登录再回来，回来后再重新渲染页面数据即可

这里有二个动作：一个是判断登录态，一个是重新渲染页面数据，有动作就有触发时机，对于判断登录态，我们是在跳转前判断，还是在跳转进需要登录的页面再判断，对于重新渲染数据当然是进入页面的时候再重新渲染，但是怎么去实现重新渲染了，对于小程序我们第一时间想到的是通过生命钩子来做，那当然就是onShow了

解决方案

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

应该能解决的方案应该有很多，这只是我在实现这个需求的时候想到的二种方案

场景方案1：跳转进需要登录的页面再判断是否是登录态，同时登录回来后通过onShow生命钩子重新渲染页面

此方案优点：就是判断登录态你不需要特定代码去判断，在服务端接口这一块做下处理即可，如果返回状态码是401或者是你和服务端沟通好的错误码时再引导去登录页，这样全局做请求拦截就行，项目中我就是有做这一块的处理，使用的是我封装好的工具方法：常用工具方法 - DCloud 插件市场已分享到插件市场，欢迎使用

此方案的缺点：在未登录的状态下，用户会看到明显的页面跳转，跳转到一个空白页面，突然又跳转到登录页，用户体验不是特别好，同时在onShow生命周期钩子里做数据重新渲染会有一个问题，这样会造成过多的网络请求，如果用户量不小的话会对于服务器造成一些压力

场景方案2：跳转进需要登录的页面前判断登录态，并记录正在跳转的页面，登录后重定向到前面已经记录的跳转页面

此方案优点：避免了onShow频繁触发导致服务器渲染浪费的问题，缺点就是你需要在每一个跳转需要登录的页面前做登录态判断，会导致代码冗余工作量增加，后期维护不是特别好

方案选择

我选择的是场景方案2

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

方案实现细节

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

.../*** 需要登录才能跳转的页面*/
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}})
})...

我在写这篇博客的时候，我发现这里代码其实有一个可优化点，你发现了吗？欢迎留言👀讨论

同时在登录页登录成功后需要做一下跳转逻辑，关键代码如下：

...
// 解决登录后跳转的问题
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接口拦截的代码：

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) => {// 如果有传就用传的，没有就去取，为了解决登录默认tokenconsole.log('---- requestConfig ----:', requestConfig)if (!requestConfig.header) {requestConfig.header = {}}// 如果header中没有Accept，则设置为application/jsonif (!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;

期望

解决问题的方法千千万，上述是我是解决登录跳转逻辑的处理方案，如果在上面二种方案中，你会选择哪一种了？聪明的你也一定有别的更好的方案，期待你的分享和留言👀，共同进步。