微信小程序开发的碎碎念

写在前面

去年的时候，我自己开发运营过一个微信小程序。就在用户数开始起量的时候，被微信封禁了，很可惜。不久前，由于部门业务的需要，我又开始转到小程序开发。到今天，对小程序也渐渐熟悉了，本文谈一谈我对于小程序开发的一些看法和体会。

注：本文仅为个人目前的观点，若有不恰当的地方，欢迎指出、讨论。本文的小程序特指微信小程序。

概况

如果用一句话来总结小程序开发，我觉得是：没什么意思。

关于这一点我也和几个前同事聊过，大部分人的感受也都是：没啥可搞的，没意思，堆业务。而业内对小程序的关注和实践，主要集中在同构上，即写一套代码，多处运行。比较知名的框架，有taro，uni-app，以及官方推出的kbone等。当然，还有一些处在放弃边缘或不再维护的框架，比如wepy，mpvue等。

关于对官方原生开发方式的关注和最佳实践等，业内谈及得不多。

微信小程序由微信团队推出，有自己的一套封闭的开发模式。而官方的这一套开发模式，对于前端工程化、编程范式演进等方面来说，并不友好。大部分开发者开发微信小程序，并不是因为小程序，而是"微信"。我想，这大概是我和我同事都觉得小程序开发没什么意思的原因吧。

一个Page写了几千行怎么办

这就是我最近遇到的问题。由于是在已有的小程序上进行新的功能开发，历史债这个东西就无法避免。已有小程序最初是用mpvue写的，但是mpvue已经不维护了，坑还有很多。于是在向原生转。所以项目处于mpvue、原生混写的阶段。

蛋疼的地方是，最核心的功能模块，依然是用mpvue实现，在使用了mixin（对，就是vue那个mixin）的情况下，index.vue 页面的代码行数依然上千行，加上mixin，整个页面的代码超过了3000行。而使用原生开发的功能模块，一个Page的代码很轻松的就到了1000行的大关。

在这里，我并不想去讨论关于性能方面的问题，而是一个更加直接的问题：这么多代码，如何更好的维护与迭代。

小程序代码复用方案

关于代码复用，第一个很自然想到的就是组件。重复的代码，我们可以抽成组件使用。小程序也为我们提供了组件方案。我们来看一个很常见的例子：用户点击页面中一个按钮，弹出弹窗，点击弹窗上的按钮后，关闭弹窗。

最常见的代码复用方案，将弹窗封装成一个组件，在page中调用即可。

// page 的 wxml<dialog wx:if="{{ isShowDialog }}" bind:click="onDialogCloseBtnClick"></dialog>
<button bindtap="handleBtnClick"></button>
// page 的 index.jsPage({  data: {    isShowDialog: false  },  handleBtnClick() {    this.setData({      isShowDialog: true    });  },  onDialogCloseBtnClick() {    this.setData({      isShowDialog: false    });  }});

上述实现方案没有问题。弹窗这个Component是完全由page控制的。但是仔细想一下，如果我在每一个page中，都要使用这个弹窗，那么每一个page中，都需要包含一个 isShowDialog 的状态，和两个处理点击的函数么？再者，如果一个page中，需要有多个类似的Component，那针对每一个弹窗，都需要在page中写上 data 和 两个对应的点击函数？

这样下来，一个page超过千行就是很自然的事情了。

另外一个情况，如果弹窗仅仅是一个展示作用，或者逻辑完全内聚，那么我们也可以使用以下的方法来实现，可以减少一些代码行数和耦合：

// 弹窗的 wxml<view wx:if="{{ isShow }}"></view>
// 弹窗的 index.jsComponent({  data: {    isShow: false,    content: ''  },  methods {    handleCloseBtnClick: function() {      this.setData({        isShow: false      });    },    show: function(content) {      this.setData({        content,        isShow: true      });    }  }});
// page 的 wxml<dialog id='dialog'></dialog><button bindtap="handleBtnClick"></button>
// page 的 index.jsPage({  handleBtnClick: function() {    const dialog = this.selectComponent('#dialog');    dialog && dialog.show('hello world');  }})

上述两种方法，是我目前想到的两种实现代码复用的方法。微信官方也为我们提供了代码复用的方法：behavior

Bahavior 其实就是 mixin。对于弹窗这个情形，用mixin实现，我觉得是更好的选择。在想要实现弹窗的组件中，引入弹窗的mixin即可，就不用再去手动写什么method了。

但是，我觉得mixin有一个很大的问题，那就是属性覆盖的问题。如果页面逻辑复杂，功能模块太多并且是多人维护，一不小心覆盖了别人的属性，那就很尴尬了。另外，mixin的侵入程度太高，在某个mixin内使用的变量，很有可能是出自其他的mixin，这样导致代码混乱，不利于维护。

其次，mixin只能在Component内使用，page内并不能使用。什么？把page就改成一个Component算了。这是行不通的。比如，page中的 onPageScroll 方法，Component里就没有。再说了，page就是page，整个弄成 component 感觉就是怪怪的。

至于为什么只允许 Component 内使用 mixin，Page内不允许使用，这一点我没有想太明白。

怎么避免一个Page几千行代码

再次强调，这里的几千行代码并不是说不好。而是几千行代码全都写在一个.js文件中，对于代码维护来说，成本太高了。怎么样把代码拆分到多个文件中呢？尽可能保持page中的代码逻辑清晰。

一个最有效，最简单的方法：将页面中用到的工具函数等，以纯函数的方式抽离，单独写到一个js文件中，在page中引用。对于一些计算、数据格式化相关的业务逻辑函数，我个人不倾向于抽离，这些逻辑聚集在一起，对于业务逻辑的体现才更加直观。光抽离工具函数的效果很有限，无法从根本上解决几千行代码的问题。

当然，合理的使用Component也是一个方法。但是页面复杂度太高，Component数量过多，而Component逻辑无法完全内聚时，Page的代码量也不会少太多。

写在后面

本文并没有介绍小程序的同构方案，比如taro等。很多团队并没有同构需求，但是也会使用taro，是因为使用react写小程序，尽管可能会有一些坑，但是写起来很爽，并且有很多的实践可以参考，可以很好的解决代码复用等问题，也不太会出现一个页面几千行代码的现象。但是，谁能保证taro这种不是kpi晋升项目呢？后面停止维护可能就是老板一句话的事情（看看mpvue吧）。

那么使用原生方式开发小程序，如何更好的解决代码共享复用的问题，减少单页面代码量太大导致的不好维护等问题。这一点，我会在实践中继续思考。你有什么想法，欢迎交流。