我在小程序工程化方面的一些实践

早期做小程序时，还是原始时代，项目结构混乱，各种冗余代码，每次迭代时由于高昂的维护成本，极为头疼。遂在一次次的更迭中完成了基础组件的初版，极为酸爽。从此之后在当时的情况下只需要关注于业务，对于通用的该封装封装，该分层分层，该解耦解耦，也出了一款独立于业务之外的基础组件。洋洋自得。

后来入职新公司，遇到的问题也是同样的，在工作之余计划将此前抽象的基础组件集成进来，发现了不少问题，其中之一就是上手极为不易，在这个过程中又有一些改进。

更迭

此前公司的小程序开发模式是：
在这里插入图片描述
此前的问题对于页面的创建是极为的不便，对于代码的调试也不方便，代码结构也没有进行分层。

接入基础组件之后，目前的小程序优化为以下结构：
在这里插入图片描述
相比之前添加了一层隔离层，好处与未来的规划可以下图解释：

当前小程序此前就采用glup进行构建的，于是我在这个基础之上添加了一些任务，使用工具自动引入基础组件，而对编写上层业务代码来说是无感知、无侵入的，还可以按照之前的原生方式写，这是它的一大优势。

目前还有的问题是页面之间的Intent通信耦合还是很严重，解决思路为可以提供一个中介者来完成，不过这个对目前来说问题不大。

目前已经完成的功能有：

开发者模式，可以用来切换环境，目前有生产，预发，测试。
对App的注册进行了代理，可以在基础层完成一些初始化工作。目前有监控的初始化。
对每个Page的生命周期与setData方法做了代理，setData在编译时替换为了setMFData。
setMFData目前对setData的调用做了节流。可以提升页面的渲染性能。
将运行时环境所提供的方法挂载到了每个页面实例下。不需要再通过wx.xx调用，可直接通过this.xx调用。这样的好处在于使业务代码与运行时api进行了隔离，也方便使用。
对此前的网络层再做了一层隔离，这一层只是用来承载网络访问，并桥接了网络监控的能力。而上层会做更多的业务处理。

将来可以做的事：

可以采用类vue的编写方式，将4个文件合并至一个文件，扩展名可以为*.mp。
可以写一个脚手架用来创建*.mp文件。
需要写一个mp-loader将*.mp转换为对应的微信文件。
可以写一个转换工具将之前的代码合并至一个*.mp文件中。

*.mp文件的结构可以如下：

// *.mp
// <!-- wxml内容 -->
<template><view id="page"></view>
</template>// <!-- js内容 -->
<script>Page({data: {},onLoad() { },reload() {},onUnload() {}})
</script>// <!-- css内容 -->
<style>#page {padding: 40rpx 50rpx;text-align: center;}
</style>// <!-- 小程序特有的配置 -->
<config>{"navigationBarTitleText": "小程序开发者"}
</config>