前情
uni-app是我比较喜欢的跨平台框架,它能开发小程序/H5/APP(安卓/iOS),重要的是对前端开发友好,自带的IDE让开发体验也挺棒的,现公司项目就是主推uni-app,我主要负责抖音和快手端小程序。
坑位
公司历史原因项目有APP端小程序端,但并不使用uni-app的一端发布所有平台,各端都有它的开发负责人,只有我负责的快手和抖音是基于一套代码发布多端的,因有需求是APP先行的,而基于uni-app的代码利用率还算是高的,于是这一次需求并不是重新从0到1开始开发,而是直接基于App的代码来做调整适配快手抖音端,去除掉一些App特有代码和在解决了一些样式兼容问题后,发现在快手小程序端其中带过滤筛选功能的商品列表显示异常,怎么切换筛选条件都没有更新商品列表。
Why?
在App和抖音小程序端上功能都是正常的,控制台也没有报错,同时也发现接口也是有发起的,于是开始去细看代码,发现App开发者为了组件复用,在商品列表组件有一处逻辑会根据当前是什么路由就请求对应接口,代码如下:
const getCurrentRoute = (index = 1) => {
const pages = getCurrentPages()
const currentPage = pages[pages.length - index]
const currentRoute = currentPage.route;
return currentRoute;
}
const getList = (params) =>{
const curRoute = getCurrentRoute();
if(curRoute === 'pages/home/index'){
getHotList({...params})
}else{
getGoodsList({...params})
}
}
当时看到这个代码我是比较反感的,为什么要根据路由去判断请求不同接口,直接外面传一个特定的key判断是哪一个页面不是更稳定,虽然代码看着不是很认同,但按理说这功能也不至于一端能用一端不能用,开始怀疑是不是快手端获取路由栈方法getCurrentPages有什么问题,为了定位错误,我通过日志打印查看路由获取是否正确,代码如下:
const getCurrentRoute = (index = 1) => {
const pages = getCurrentPages()
console.log('---- getCurrentRoute ----:', curRoute);
const currentPage = pages[pages.length - index]
const currentRoute = currentPage.route;
return currentRoute;
}
至此才发现问题所在,在抖音端打印的路由和快手端打印的路由有一小点区别,快手端会在开头多一反斜杠:
解决方案
方案1:比较取巧偷懒的方法就是从返回看pages/home/index是二个都有的,那只判断路由是否包含pages/home/index即可,示例代码如下:
const getList = (params) =>{
const curRoute = getCurrentRoute();
if(curRoute.includes('pages/home/index')){
getHotList({...params})
}else{
getGoodsList({...params})
}
}
方案2:重写不通过路由判断,通过从外面传key判断当前组件是用在哪一个页面,来请求不同的接口,个人觉得此种方式是最稳妥的,也是我推荐的。
思考
小于uni-app跨平台的项目,虽然uni-app已经处理了绝大部分的平台差异问题,但是或多或少会有一些是平台处理漏的,遇到这种一端可以另一端不行的问题,可以先考虑是不是使用了一些平台有差异的API,手动把差异抹平即可,对于实在官方都说明有差异的,那就用好uni-app的条件编译来处理吧。
标签:index,const,快手,app,抖音,uni,pages,路由 From: https://www.cnblogs.com/xwwin/p/18475071