微信小程序开发，如何优雅地兼容

小程序的功能不断的增长，可是旧版本的微信客户端并不支持新功能，因此在使用这些新能力的时候须要作兼容。

关于单个 API 如何兼容，微信官方提供了兼容文档，所以咱们这里再也不赘述。
下面主要讨论在整个项目如何优雅地处理兼容问题。

问题

若是在每处须要兼容的地方都写上一堆兼容相关的代码，随着代码量增长，会出现如下问题：

• 代码难以阅读
• 兼容方案有变更时，须要改动多处
• 随着时间推移，你的代码才是最须要而且是最难兼容的

思考

最理想的状况是不须要任何兼容处理，所以能够反推出兼容性处理的代码并非代码正常流程中的一部分，基于此：

• 兼容的细节没必要暴露
• 兼容的方案应该统一
• 兼容的方案可方便地变更

解决方案

1.将兼容方案隐藏，对外提供接口便可

好比 wx.showLoading 是在 1.1.0 版本以后才提供的，对于以前的版本须要兼容。
咱们选择将其放在 show-loading.js 中，内部进行兼容性相关处理，并对外提供 showLoading 方法。
这样调用者只需调用 showLoading 方法便可，不用考虑兼容性的问题，并且若是兼容的方式有变更，只需改动 show-loading.js 一处便可。

2.兼容的处理还有共性能够抽象

兼容处理多了以后咱们会发现，对兼容所作的处理无非两方面：

• 支持该方法时，直接使用对应方法
• 不支持该方法时，作一些兼容处理

所以这种模式咱们又能够抽离出来，这样作固然有一些好处：

• 减小重复代码
• 作一些共性的处理时，咱们又只用改动一处（好比当不兼容官方 API 时加上对应统计，用于分析当前应用跨版本的状况）

好比咱们抽离出这样一个简单的 compatible.js 用于处理兼容时的共性问题：

以前的 showLoading.js 咱们能够这样写：

简单吧 :)，这种写法的意思是兼容时正常展现 loading 便可，不兼容时则不展现。

固然可能有完美主义者会以为『怎么能不展现呢？我就是要展现！』 那么咱们能够这样写：

用 wx.showToast 伪造了一个 showLoading。

3.文件组织

兼容性的文件可能会愈来愈多，对于我这种有收拾的人，看到全部东西散乱地扔在一个抽屉里确定是不能忍的...
所以咱们能够多用几个小盒子把它们分门别类地装起来。小盒子怎么选呢？其实官方已经给出了答案，官方 API 是按照不一样的功用分组的，所以咱们拿分组当『盒子』便可。
最终的文件组织像这样：