經過測試，鬧心律師小程式第二期也即將上線了，而鬧心對於小程式有怎麼樣的開發實踐呢？ 小程式在千呼萬喚出來之後，帶來了大量的開發的吐槽，但儘管我們再怎麼嫌棄小程式語法，我們也無法否認微信給小程式所帶來的流量以及收益，也必須看重小程式，也不得不去學習小程式 那麼我們開發小程式應該怎麼去開發呢，熟悉前端的 ...
經過測試，鬧心律師小程式第二期也即將上線了，而鬧心對於小程式有怎麼樣的開發實踐呢？
小程式在千呼萬喚出來之後，帶來了大量的開發的吐槽，但儘管我們再怎麼嫌棄小程式語法，我們也無法否認微信給小程式所帶來的流量以及收益，也必須看重小程式，也不得不去學習小程式
那麼我們開發小程式應該怎麼去開發呢，熟悉前端的我們開發起有小程式有什麼困難嗎？
困難不至於，圍繞小程式的官方文檔甚至是可以輕鬆的開發，就是開發的體驗的麻煩倒是不少
首先來看看小程式的架構
初始化一個預設配置的小程式項目
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 方法
到這裡我們也可以很清楚的看到鬧心律師小程式基本上是無需很多的其他配置或者插件就可以順利的開發，
一句話，看著文檔擼起來，輕鬆搞定業務。
小程式雖然是 小 程式，現在也越來越"龐大"了起來
我期待小程式的生態的生長，也在觀望各種轉編譯成小程式的框架
目前鬧心律師還是處於使用原生開發的狀態，如果有更多的實踐，我會詳細分享給大家
