做完两个实战案例后，我总结了高效编写微信小程序的方法

2017-02-19 11:37:00

何六六：微信小程序是一个工程，就和盖房子一样，打好了地基，才能保证后续工程师建立在可靠牢固的基础上。笔者需要经常新建项目，每次都要重复“修改项目结构 -> 从老项目中复制粘贴文件 -> 删除一些老项目中代码”这样的过程，实在费心费力。如何高效编写微信小程序呢？来看腾讯工程师总结的这个方法！

另一个痛点是：每次新建小程序页面要生成三个文件名相同的文件 ( .wxml、.wxss 和 .js )，命令行太长（据微信同事：也可以在 app.json 的 pages 字段下添加新页面的路径，保存后也会生成对应的文件）。

因此，阅读本文需要对小程序开发稍有了解（简易教程指路）

目标

我们现在有两个目标：

根据通用模板新建项目

一键新建页面目录以及在目录中的三个文件：.wxml、 .wxss 和 .js也可以直接在 app.json 的 pages 字段创建页面，保存后生成这三个文件。笔者没有采用这个方法的缘由一个是开始时不知道有此功能，另一个是不合平时的操作习惯，再者想到 js 文件初始化后，需要引入常用库，要插入代码片段，所以保留了这个功能。
这两个需求其实很简单，不需要 GUI，所以我们可以做一个 npm 命令行工具。想象一下这个命令行用起来应该是什么样的呢：

用流程图示意就是：

实现

正式开始之前，请先确认本地的开发环境，笔者的本地环境是：

我们把问题分解为三步：

实现命令行工具，可以在任意目录直接运行
通过输入不同的命令行参数，以执行不同的功能
考虑项目模板的存放位置，是集成到工具中，还是和工具分开呢
不用担心，都很容易解决，我们一个个看。

命令行工具

package.json 中有一个字段是 bin：

这个字段可以将开发者希望执行的脚本注册到环境变量 (PATH) 中，不同的 key 对应执行不同的脚本。也就是说现在，当我们直接在命令行中执行：

等价于在 terminal 中执行：

第一个问题轻松解决，关于 bin 字段更多信息请参考 npm 文档中 package.json 一节。

命令行参数

执行 index.js 时，可以通过 process.argv 获取执行时的参数，但是要从参数数组中拆分出参数无疑很麻烦。不过，npm 发展至今，处理命令行参数的库肯定存在，就是 commander。简单好用易上手，那么第二个问题也解决啦。

项目模板的存放位置

考虑项目模板的存放位置，是集成到工具中，还是和工具分开呢？

笔者选择分开管理。

在一个单独的模板代码仓库中管理模板内容，方便我们维护。目前的模板还比较简单（详见下文“模板详解”），只有标准目录结构，预期后面会加上自动化的部分（比如 less -> wxss），所以未来会改动比较频繁。

download-git-repo 可以把给定地址的仓库内容拷贝到执行目录中。API 简单，所以就是它了。

问题都解决了，现在就让我们看看伪代码（注意：伪码中没有考虑出错情况）：

使用

在编写好了这个工具之后，只需要在本地全局使用的话：

在本地开发过程中，如果更新了开发版本的代码，需要更新同步到全局，这时候需要执行：

就会看到安装到环境变量中的工具目录地址已经和开发目录关联起来了：

使用起来是这样的：

△ 模板和插件地址将附在参考资料一节中

发布 npm 插件

如果和笔者一样，希望在多个机器上使用这个工具，可以选择发布到 npm 官网上。发布步骤非常简单，基本上就是：

不过笔者考虑到，项目模板毕竟是因人而异的东西，所以选择了发布 scope package，也就是在插件的 package.json 中的 name 字段使用 @scopeName/wxapp-generator 这样的值。

如果你也有类似的想法，并且也是个 npm 免费用户，那么发布的时候要执行：

scope 对使用没有任何影响，但是安装的时候要记得带上 scope name 执行：

模板详解

一千个人中有一千种项目模板。根据业务/个人爱好不同，大家的项目模板可能也相去甚远。笔者自觉目前的模板用起来还不错，将在这一节介绍一下。以下是项目的文件结构：

之所以采用这样的结构，是希望尽可能解耦 UI 逻辑与业务逻辑。但是由于完全解耦是不可能的，基本思路是单纯的“变量分离”。通常 UI 的改变是通过 class 的切换或者内联样式的调整，所以笔者的思路，是将“要切换的 class”或者“要调整的内联样式”作为变量，由于大部分情况下业务逻辑和 UI 变化是联动的，通过抽离出来的变量，实现在业务逻辑中简单直白地改变 UI。

可能看到这里，读者会有些困惑，那让我们直接以「企鹅听书」为例，具象地看看笔者是怎么做的吧。听书的界面会出现变化的时以下两种场景：