经过测试，闹心律师小程序第二期也即将上线了，而闹心对于小程序有怎么样的开发实践呢？
小程序在千呼万唤出来之后，带来了大量的开发的吐槽，但尽管我们再怎么嫌弃小程序语法，我们也无法否认微信给小程序所带来的流量以及收益，也必须看重小程序，也不得不去学习小程序
那么我们开发小程序应该怎么去开发呢，熟悉前端的我们开发起有小程序有什么困难吗？
困难不至于，围绕小程序的官方文档甚至是可以轻松的开发，就是开发的体验的麻烦倒是不少
首先来看看小程序的架构
初始化一个默认配置的小程序项目
app.json 里面定义小程序的路由，以及全局的一些配置
app.js 进行注册程序 小程序的生命周期以及监听整体小程序的活动
page(路由页)以及 component(组件) 页 都由
- .json 单独的页面配置 可以覆盖全局配置
- .js 定义方法以及属性 有完整的页面/组件的生命周期
- .wxml wxml 有自己的作用域 除了引入 wxs 其他只接受 js 中从 data 传递过来的值
- .wxss 算是 css 的弱化版
我们可以打开小程序的开发工具，查看控制台的 Sources 选项，点击里面的文件详情可以很清楚的看懂，小程序是由 webpack 打包的
并且随机的监听了本地的一个空闲端口
小程序视图层使用 webview 渲染，逻辑层使用 JSCore，通过 JSBridage 进行通信 逻辑层改变数据后通知视图层触发视图层的局部更新，并且在加载页面的时候预先加载多一个 webview 用于渲染下一次的路由
总的来说，小程序提供了自己的一套标签并提供 Native 方法，并且禁用了 Dom API，只能使用 setData 去更新视图，另外值得一提的是小程序把 Function 重写了，
而小程序已经把大部分都处理好了，剩下的只需要写好我们的业务就可以了，
在我写小程序来说，还是很顺畅的，那么感觉到的麻烦是什么呢？
- 配置繁锁，事件命名规则不一，生命周期名字不一，且概念驳杂
- .wxss 仅支持部分 CSS 选择器 我们平时都是使用 less, sass 等预处理语言，在这里回到写原生 css 没有很大的意义
- wxml 不支持使用直接使用 js 方法，即是无法通过 js 使用过滤器等
- 触发函数传递参数 只能通过 data-xxx 的方式来传递，并通过 event 的来拿到我们绑定的参数
闹心律师小程序的文件 dist 目录
├── app.js
├── app.json
├── app.wxss
├── pages // 目录
├── models // 状态数据管理
│ │── store.js // 导入 index 并且注册导出 store 实例
│ │── index.js // 导入各个模块 统一导出
│ │── pay.js // 支付模块
│ ├── im.js // 聊天IM模块
│ ├── order.js // 订单模块
│ └── ...略 // 各个页面或者组件的状态
├── libs
│ │── WebIM.js // 环信聊天的 sdk
├── utils
│ │── Base64.js // 处理一些加密解密
│ ├── cnyUtils.js // 一些工具类
│ ├── md5.js // md5 加密
│ ├── moment.js // 处理时间的一些函数
│ └── index.js // 综合导出工具类
│
├── static // 一些静态的图片资源
├── helper // 一些纯业务状态以及一个 util.wxs 作为状态过滤器文件
├── template // 一些纯展示的组件
├── components // 纯组件
├── container // 有状态组件
├── request // 封装 wx 的 request 并返回 Promise
├── service // 导入 request 并导出每个封装好接口地址的请求函数制定开发规范
虽然现在只是我一个人在撸小程序，但是一个项目的开发规范还是必不可少的，控制命名以及代码风格，采用 eslint，命名使用驼峰式
写新方法方法必须使用 JSDoc 进行注释和类型
css 隔离，通过公共 import 导入，组件开头必须大写
git 分为主分支，测试分支，开发分支，以及 bug 分支
使用 webpack 进行编译打包，分离开发环境以及生产环境，再进行小程序的上传打包
关于开发组件的体验
目前小程序的组件的体验对于开发者来说还是很差的，它必须先在 json 配置里必须先定义是组件即 'component':true
一个组件的 .js 文件 大概的属性如下
Component({
externalClasses: ['my-class'] //接收外部的class
behaviors: [], //mixin 复用函数属性
options: { //也许你需要？
multipleSlots: true // 在组件定义时的选项中启用多slot支持
},
properties: {
//相当于React的propTypes + defaultProps
string: {
type: String,
value: 'default value',
observer:function(){} //监听string的改变 改变后触发
},
number:Number //也可以直接声明类型即可
},
data: {}, // 相当于React的state
created() {}, //组件即将挂载
attached() {}, //组件挂载完成
detached() {}, //即将卸载
relations:{ //组件的通信很麻烦, 必须预先定义
'parentName':{
type: 'parent', // 关联的节点是父节点
// ...略方法
}
'childName':{
type: 'child', // 关联的节点是子节点
// ...略方法
}
}
methods: {},//放事件回调及其他方法
});可以看到一个组件的生命周期其实和 page 是不一样的命名，这就令人恶心了
properties 是不可以传递函数的，data 以及 properties 是共通的数据，无论你访问哪一个都能够获取两个对象的数据
组件的样式是限定自己的作用域的，不能够直接从 app.wxss 中继承
事件的通信是 eventbus 的方式 使用 wx 的 triggerEvent 方法来进行通知
虽然不能够传递函数给组件，我们却可以在父页面可以使用 selectComponent 来选择子组件实例，
并且通过子组件的实例可以使用子组件的方法 进行控制反转 回调函数作为参数传递过去并进行深层传递回调
我们自己跑测试一个 component 的例子，打开控制台查看 wxml 可以看到渲染的组件 有一个#shadow-root 就知道小程序的组件是基于 Web Component
有兴趣的可以去看看 MDN 看看
状态管理
那么复杂点的业务必不可少的就是数据与页面的解耦以及多层传值通信问题，那么小程序的状态管理是可以定义在 app 中，在 page 或者 component 中使用 getApp()获取小程序实例，调用 app.js 里定义的方法或者属性
那么需要页面之间共享的属性以及方法， 我们也不可能全部定义在 app.js 中
在闹心律师小程序我是在 models 文件夹中管理状态，写了一个 wenaox 进行状态管理，通过 npm 安装，构建 npm 后就可以使用 import 全局导入了
通过多 contro 进行管理 注册 store 实例。
在 app.js 导入 store 实例，使用 Provider 注入后
即可在 page 使用 orm 注入所需要的方法和属性
在 component 则使用 ormComp 方法注入
性能优化
减少 setData 的次数以及一次更新的数据量，在这里 wenaox 是在 page 页隐藏以及卸载的时候均取消监听避免后台占用资源
关于其他的性能优化，都是通用的，减少请求，图片大小，懒加载，压缩等等
运维
日志／监控／分析上报系统
目前采用的是小程序自带的数据分析以及上报预警功能，小程序目前可以建立 128 个监控事件，
而日志上报也是自由定义需要记录的操作日志，5M 作为上限 超过 5M 废弃旧的，然后可以通过设置 Button 组件 的 open-type 为 feedback 来让用户上传日志。
小程序新版本上线
通过 getUpdateManager 方法，获取新的版本信息，提示用户更新。
总结
在开发小程序的过程中，可能会因为很多限制因素，而导致开发体验并不是非常友好
但小程序自身提供了开发工具，默认的打包，以及各种 Native 方法
到这里我们也可以很清楚的看到闹心律师小程序基本上是无需很多的其他配置或者插件就可以顺利的开发，
一句话，看着文档撸起来，轻松搞定业务。
小程序虽然是 小 程序，现在也越来越"庞大"了起来
我期待小程序的生态的生长，也在观望各种转编译成小程序的框架
目前闹心律师还是处于使用原生开发的状态，如果有更多的实践，我会详细分享给大家