- 需求的场景描述（希望解决的问题）
小程序提供API接口大部分都是异步接口，但是有些接口又依赖于其他接口的调用结果，这就造成为了实现一个接口调用需求而进行多层代码嵌套，代码相当不美观，也不利于开发者维护。
例如：要获取当前连接的WiFi信息，则需要三个API的嵌套调用来实现获取WiFi信息，然后再与服务器进行交互：
success(res) { const networkType = res.networkType if (networkType === 'wifi') {//判断是wifi环境 wx.startWifi({ //初始化WiFi success(res) { console.log(res.errMsg) wx.getConnectedWifi({ //获取WiFi信息 success(res) { console.log(res.errMsg) wx.request({ //信息获取成功，与服务器进行交互 url: 'test.php', //仅为示例，并非真实的接口地址 data: { x: '', y: '' }, success(res) { console.log(res.data) //服务器返回成功后进行页面处理 //TODO } }) } }) } }) } }
|
以上代码除了繁琐不美观之外，还不利于维护
- 希望提供的能力
希望官方团队能将异步API实现可指定异步或同步，或者是将API封装成Promise对象，这样开发者可方便自由的通过Promise对象来模拟异步同步，还可以简化接口嵌套，简化代码，方便维护。
之所以希望官方团队将异步API封装成Promise对象而不是自己去封装，是基于良好的版本升级的考虑，如果是自己去封装，万一某次版本升级将某些API改变或者废弃，或者新增某些API，这对于开发者来说，去维护自己的封装也将是很大的开发成本。
既然小程序支持ES6的转码，那么，个人认为，如果官方团队能将所有的异步API升级为返回Promise对象，那将是对开发者相当友好的一件事，会增加开发者的热情和积极性，同时也更利于开发者维护代码。
- 补充：
其实我觉得学习promise的简单使用的成本并不是太高，尤其是跟多层嵌套调用、不利于维护等比起来，真心个人感觉这点学习成本很低。
当然，也不是没有解决办法， 比如可以通过在全局的app.js中增加一个配置项，用来指定是否全局开启异步API的promise调用方式，或者是在单个API中增加一个配置项，来指定当前API是使用原本的异步方式还是使用promise方式。
这只是个人建议，仅供参考。但我真心觉得异步API使用promise肯定会越来越成为更多开发者的呼唤和心声的！
用promise,我用的都是自己封装的promise
老铁，promise、async function了解一下，别把无知当个性，还有，这里也吐槽一下wx的api，为啥wx的api一开始不是promise来设计的，为啥小程序内部不自带regeneratorRuntime，看来小程序的架构也是垃圾中的战斗机呀
老铁,这又不是小程序的锅,是javascript的锅啊. 但是不会promise啊?不会await啊?
不会百度啊,去学啊.
赞成promise
感觉用promise的学习成本并不高，相比而言，我更愿意用学习promise的学习成本去换更友好的调用方式和更简洁、更易维护的代码。
另外，也可以考虑在调用接口的时候指定是否使用promise不是？或者在app.js中增加一个全局配置项，用来开启异步API是否是通过promise的方式来调用。
但是你也要考虑下不会用Promise的人呀~