基于mpvue构建微信和支付宝小程序（1）

（1）----- 基础架构篇

why?为啥会有这个系列？

无论是百度和google，关于mpvue构建小程序的项目讲的都是管中窥豹，没有一个系统的讲解。 本系列是关于基于mpvue同时构建微信和支付宝小程序的笔记，而网上大部分教程都在聊微信小程序，支付宝小程序大家聊的都很少，因此在该系列文章当中会基于大家在做同构支付宝和微信小程序当中一定会遇到的小程序的问题做一个深入的总结和分析，讲一些大家没有踩过的坑，讲解一些大家没有看过的东西。

what? 主要是哪些问题？

在同构微信和支付宝小程序时，大概问题分为以下几类 1. 授权 2. 支付 3. 登录 4. 缓存 5. api的封装 6. 基础组件（弹窗，提示组件） 7. 获取系统信息 8. 动态添加css 9. vue的支持情况 10. 部分微信有，支付宝没有，支付宝有，微信没有的属性 11. 可能的埋点

大致上分为10类，会分为不同的篇目去讲解这些问题（埋点看大家的情况，会选择性的讲解一部分）

## 基础架构

在做一个同构版本的基础架构之前，我们需要首先了解的是mpvue有没有提供了同构的能力？ 官方给出的答复是 ## mpvue之提供前缀的弥合，具体的api相关的兼容需要开发同学自行弥合

想想也能理解

1.1 两个的小程序迭代的可能越来越不同，mpvue也没办法帮你做所有的事情，这不是开源作品应该关心的小细节

1.2 mpvue本身已经作了前缀的弥合，剩下的坑其实也不是特别多？（其实还挺多的）

基于上面的原因，在做之前想好怎么做？做哪些事情还是很重要的！！

聊聊个人对同构小程序的基础架构的理解

1. 分而治之
2. 合而治之
3. 尊重不同

上面三点是个人对于同构小程序的理解，一点点的来解释

### 分而治之

分化治理，始终是程序开发过程当中必不可少的理念，或者换个说法更熟悉，自顶而下。

哪些需要分而治之

1. 支付

2. 登录

3.埋点

就目前实践来看分而治之对于这三点是最为合适的

#### why? 1. mpvue没帮忙做封装 2. 函数名和参数存在很大的差异 3. 使用第三方埋点和数据统计的sdk，如果人工去弥合差异会给自己后面的开发带来一定数据风险和增加开发成本，而sdk厂商也没有做同构的sdk的意愿

#### how? 怎么做？

分化，简单来说就是分离不同平台的支付和登录的逻辑，然后在基础函数入口收束整个的代码，达到分而治之的目的

举个简单栗子

从一定程度上就缓解了支付和登录的尴尬，同时也能在一定程度上动态的加载对应的基类，然后去在main.js当中去实例化类。

这样即使平台越来越多也不过是把if else 换成switch case （如果将来需要适配100个平台，当我没说）

合而治之

所谓的合而治之，就是所谓的封装，既然mpvue没有帮忙封装函数，那么在实现方面就可以需要让自己封装。 核心的思想是收紧出口，让调用者关心的是如何实现业务，而非去适应平台。 简单的举个栗子 alert,toast,dialog,以及后面的持久性缓存，这些都是需要去弥合的。 弥合的api大概上可以分为以上几大类。

how？那么如何弥合呢？

收紧出口！！！！

举个简单的例子

toast,需要内部去做判断到底是使用哪个方案去实现

调用者只需要，

比如使用 this.$dialog.toast('aaa') 就能实现toast效果。

### 尊重不同

看了前面的两个，你肯定觉得你这三个观念不是自相矛盾吗？其实不矛盾，其实就是改用千斤顶的地方不用螺丝刀，其实就是这么简单

### what?哪些东西需要尊重不同呢？？

比如授权，授权微信小程序是按钮触发，而支付宝小程序是方法触发，这种理念上完全不同的东西就在html/wxml/axml上是弥合不了的，

既然弥合不了，这种东西就直接在dom里面根据平台做判断好了，完全不需要纠结。

但是还是建议收紧出口

### ps:

对于一些细节问题，会在后面的系列中仔细聊一些坑（写东西真的是好累哦，输入和输出是完全不一样的两个概念，说出来和写出来也是完全不一样的两个概念）