对此uni-app是提供了有了condition https://uniapp.dcloud.io/collocation/pages.html#condition ,它是在pages.json中进行手动配置,更在于传入到页面的参数是并不容易拿到的。
因此希望可以通过某种方式可以最终达到,重新编译页面后,页面依旧可以停留在原先的页面,并且数据参数都是要与原来保持一致。
如果我能进行uni-app中的路由拦截,并将拦截到的路由设置在storage中,编译后,再次进入到首页时,使用navigateTo直接跳转到原来的页面,一切便大功造成。
对于uni-app中的路由拦截可以使用官方的拦截器, https://uniapp.dcloud.io/api/interceptor.html#addinterceptor 。 也可以采用重写路由的方式,如下:
问题在于,我们使用的原生的顶部栏,返回上一页,并不能被拦截到。而在微信小程序中,事件onBackPress是不起作用的。
因此这种方式不能很好的解决。 https://uniapp.dcloud.io/tutorial/page.html#lifecycle
基本的思路是在页面或者应用的销毁的销毁的生命周期时将当前页面的信息存储到storage,然后在页面加载时,跳转到原先的页面。
最终很遗憾的是,再次编译时是没有进入到 页面生命周期 onUnLoad中,也没有进入到组件生命周期 beforeDestory中的。
在开发环境中使用定时器,不断将当前页面的值写入到Storage中,编译再次进入时跳转。
通过了这种方式,特别对于层级很深的页面,不需要再编译之后一层层去点到之前的页面了,开发效率被大大提升。
关于怎么设置不同小程序请求一套后台怎么区分相关资料如下这个地址 后来查看开发文档说是不可变的固定的,也就是说这个地址是固定格式,里面存在小程序的appid,这就好办了,那小程序访问的接口中我们通过appid 拿到不同小程序的appid 和 秘钥 这样就可以区分小程序了,然后做不同小程序的授权 和 所以 关于 微信api的调用都可以实现。
也就是说 同一个微信号 针对 4个小程序,在业务逻辑上 是4个不同的 user_id 因为openid都不同。
方案确定了 ,那就是实现了,实现就很简单喽。。。
我拿我的后台接口举例哈,我接口是用php写的。无论哪种语言都是大差不差的。
我先把所有小程序的 appid 和秘钥 在配置文件配置好:
接下来就是在路由拦截的地方做个权限判断,因为所有接口都要通过一层路由中间件做分发处理,权限验证:
那这就是获取小程序访问接口的appid 如果不存在 或者 appid 不正确那就直接 提示用户非法请求。
如果正确可以获取配置信息 那就走正常业务处理。。。
因为在中间件里面我们已经可以获取到配置文件信息了,所以 每次请求我们都会携带上appid 给后面的逻辑,也就是说 所有的请求 都会携带appid 在走到业务层面的时候 appid 存在 且 正确
这时候我们根据appid 再去初始化 config 配置信息 给以后所有涉及 小程序api 调用的业务做 配置。
这样就能实现一套api 多个小程序公用的 区分设置了。啦啦啦啦
最后业务实现了,我们最后最好在 数据库当中 留存一下 是通过 哪个小程序进来的 ,这样我在数据库user 表中 添加了一个 appid的字段
这样就很容易区分哪个用户是通过哪个小程序进行访问授权的。
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)