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

小程序的功能不停的增多，可是旧版本的微信客户端并不支持新功能，所以在广州小程序开发采用这些新能力的同时需求做兼容。关于单个 API 怎样兼容，微信官方提供了兼容文档，因而我们这里不再赘述。下面重要讨论在整个项目怎样优雅地处理兼容问题。

问题

假如在每处需求兼容的地方都写上一堆兼容有关的代码，伴随代码量增多，会出现以下问题：代码难以阅读，兼容方案有改变时，需求改动多处，伴随时间流逝，你的代码才是最需求并且是最难兼容的。

考虑

最理想的情形是不需求任何兼容处理，因而能够反推出兼容性处理的代码并非代码平常步骤中的一部分，基于此：兼容的细节不必暴露，兼容的方案应该统一，兼容的方案可便利地改变

解决办法

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

例如 wx.showLoading 是在 1.1.0 版本以后才提供的，对于之前的版本需求兼容。我们选择将其摆在 show-loading.js 中，内部进行兼容性有关处理，并对外提供 showLoading 形式。这样调用者仅需调用 showLoading 形式即可，不用思考兼容性的问题，而且假如兼容的方法有改变，仅需改动 show-loading.js 一处即可。

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

兼容处理多了以后我们会发现，对兼容所做的处理无非两方面：支持该形式时，直接采取对应形式，不支持该形式时，做一些兼容处理，因而这种模式我们又能够抽离出来，这样做当然有一些好处：降低重复代码，做一些共性的处理时，我们又只用改动一处(例如当不兼容官方 API 时加上对应统计，用作探讨当前软件跨版本的情形)，例如我们抽离出这样1个简单的 compatible.js 用作处理兼容时的共性问题：

之前的 showLoading.js 我们能够这样写：简单吧 :)，这种写法的意思是兼容时平常展示 loading 即可，不兼容时则不展示。当然也许有完美主义者会觉得『怎么能不展示呢?我就是要展示!』 那么我们能够这样写：用 wx.showToast 仿冒了1个 showLoading。

3.文件组织

兼容性的文件也许会越来越多，对于我这种有收拾的人，看见所有东西散乱地扔在1个抽屉里一定是不能忍的...因而我们能够多用几个小盒子把它们分门别类地装起来。小盒子怎么选呢?其实官方已经给出了答案，官方 API 是依照不一样的功用分组的，因而我们拿分组当『盒子』即可。