场景描述:
众所周知,许多的小程序,许多的业务场景,都需要进入小程序前准备好一些基础数据,才能进入页面
比如:全局皮肤设置,切换门店,系统配置等功能都需要先拿到参数后才能使用
存在问题:
小程序的执行顺序app.js onlaunch 肯定是在page onload方法之前确实没错,因为同步执行,虽然onlaunch方法先执行,可能onlaunch还没执行完呢都已经进入到page 的onload方法了,会造成数据异常和系统错误。
当然一些解决办法能解决这类问题:比如等待、比如判断是否加载完成,没有再处理或者等待直到完成再处理页面业务,又或者Promise处理等等吧,反正大家再没办法的情况下想出了一些不是拌饭办法的办法。但这期间会造成N多的冗余代码和不必要的麻烦。而且有时你根本不知道用户进入的第一个页面是哪个(比如分享),所以要把所有有可能成为第一个入口的页面都加上,困难多,BUG多。
疑问:
微信小程序为什么不只支持先onlaunch----onlaunch执行结束后 --- 执行page 的onload的模式呢?
业务场景需求量少?没有考虑到?技术问题?
建议:
官方给出onlaunch 执行然后同步进onload的模式肯定是有道理的,而且符合大部分人的利益的。但也看到了有许多的开发这再提这样的问题。
能不能微信小程序从框架上解决,比如增加一个全局配置,默认就是目前模式,有需要的配置下,就能实现先onlaunch----onlaunch执行结束后 --- 执行page 的onload方法。
能不能微信小程序从框架上解决,比如增加一个全局配置,默认就是目前模式,有需要的配置下,就能实现先onlaunch----onlaunch执行结束后 --- 执行page 的onload方法。
能不能微信小程序从框架上解决,比如增加一个全局配置,默认就是目前模式,有需要的配置下,就能实现先onlaunch----onlaunch执行结束后 --- 执行page 的onload方法。
或者在onlaunch 方法前加个标识,有就是onlaunch 执行结束后(重点:执行结束后,不是执行后)再跳转到page
楼主说的对,本身请求一次就可以的的数据,如果用promise会请求多次,反正是各种方法都会无形增加很多代码,尤其是生成的二维码这块,扫码进入确实也要走APP.JS,但比如OPNEID还没获取到,打码进入的一些参数就不能用,感觉楼主说的有同感,在APP.JS里加一个判断,某个请求得到结果再进行下一步为什么不可行呢
4年了,还没有改进。这个一直都需要!
你这个提议好比开了多核加快速度,让你觉得不好控制,你想强制启用单核。一核有难,多核围观?你说的那些全局操作都是可以做本地存储的,另外个人认为即使做成异步也没啥问题啊,你全做成同步操作才是毫无用户体验。