本主(zhu)題(ti)雖然(ran)在其它地方講了很多(duo)次，但還是(shi)有非(fei)常多(duo)新內容。因為很多(duo)東西(xi)正在做或(huo)者想(xiang)要做。本次分享主(zhu)要分為以下幾個部分：

WePY 的介紹

WePY 的用戶

上面展示的(de) WePY 用(yong)(yong)戶不是全部(bu)的(de)數(shu)據。因為沒有辦法讓(rang) WePY 用(yong)(yong)戶主(zhu)動上報自己在(zai)使用(yong)(yong) WePY，所以我(wo)只列了(le)我(wo)知(zhi)道的(de)在(zai)使用(yong)(yong) WePY 的(de)公司，數(shu)據比較有限。

就我(wo)所(suo)知道的，最近有一個刷爆朋(peng)友(you)圈的小(xiao)程序(xu) —— 騰(teng)訊疫(yi)苗，前端采用(yong)的 WePY，后端用(yong)了騰(teng)訊開源(yuan)的 TARS 項(xiang)目。微信支付內部也有大量小(xiao)程序(xu)在使用(yong) WePY 框架。

右邊(bian)貼的(de)聊天記錄是我(wo)在 WePY 交流群(qun)收集(ji)到的(de)用戶反(fan)饋(kui)，就反(fan)饋(kui)的(de)內(nei)容來看(kan)，有(you)很多感謝的(de)話(hua)，說(shuo)明 WePY 這個框架確實能幫(bang)助開(kai)(kai)發者提高自己的(de)開(kai)(kai)發效率。嘿嘿，我(wo)沒有(you)貼 WePY 的(de)負面反(fan)饋(kui)，因為我(wo)擔心一頁 PPT 不夠(gou)貼 :eyes:。

WePY 的數據

WePY 項(xiang)目在 Github 上(shang)現(xian)在有(you)13900多(duo)個(ge) Star。拿其它前端(duan)框(kuang)(kuang)(kuang)架(jia)(jia)(jia)對比，Vue、React 等(deng) Star 數可(ke)能(neng)達(da)到(dao)了(le) 10W+，但(dan)(dan)是(shi)(shi)(shi)它們(men)都是(shi)(shi)(shi)國際(ji)的項(xiang)目。WePY 這(zhe)(zhe)個(ge)項(xiang)目由于微信小(xiao)程(cheng)序(xu)的原(yuan)因，算(suan)是(shi)(shi)(shi)一個(ge)國內(nei)項(xiang)目，能(neng)有(you)13000多(duo)個(ge) Star 還(huan)是(shi)(shi)(shi)相當不(bu)錯的。Star 數多(duo)不(bu)一定(ding)代表 WePY 這(zhe)(zhe)個(ge)框(kuang)(kuang)(kuang)架(jia)(jia)(jia)好，但(dan)(dan)是(shi)(shi)(shi)能(neng)表明(ming)小(xiao)程(cheng)序(xu)這(zhe)(zhe)塊流量(liang)很(hen)大(da)，開(kai)發(fa)小(xiao)程(cheng)序(xu)也非常(chang)有(you)前景(jing)。 開(kai)發(fa)者們(men)需要 WePY 這(zhe)(zhe)樣(yang)的框(kuang)(kuang)(kuang)架(jia)(jia)(jia)來提供(gong)幫助。這(zhe)(zhe)也是(shi)(shi)(shi)為(wei)什么后來出(chu)現(xian)了(le) Taro、mpvue 等(deng)類似的非常(chang)優秀的框(kuang)(kuang)(kuang)架(jia)(jia)(jia)。

issues 目前(qian)有1300多個(ge)。這(zhe)意味著(zhu)我每天起(qi)床(chuang)都(dou)有超(chao)過10條 to-do list 需要處(chu)理。加(jia)上每天還(huan)有公司的其它事(shi)情需要處(chu)理，比較頭大。

 pull requests 目前(qian)有320多(duo)條。相(xiang)比其(qi)它開(kai)源項目，這個 PR 數量相(xiang)當不錯，非常感(gan)謝為 WePY 作貢獻的開(kai)發(fa)者們。

用(yong)戶數(shu)有4000多。這(zhe)個(ge)數(shu)據的來源我是統計的我建立(li)的 WePY 交流群(qun)，目前這(zhe)個(ge)交流群(qun)里有 4000 多人。

WePY 是什么

將 Web App 和小(xiao)程序(xu)進行對比(bi)。Web App 和小(xiao)程序(xu)在(zai)功能(neng)上類似， Web App 在(zai)開發的(de)時候，可(ke)能(neng)使用(yong) Vue.js 作(zuo)為(wei)其核心(xin)庫，用(yong) Webpack 進行打包(bao)。在(zai)微(wei)信小(xiao)程序(xu)中，大家可(ke)以(yi)簡(jian)單(dan)的(de)將 WePY 理(li)解為(wei) Web App 里的(de) Vue.js + Webpack 的(de)合體。

WePY 的特點

WePY 在開發中到底幫助開發者做了什么事情(qing)呢？WePY 又有哪些特(te)點呢？

1. 腳手架：它提供了一個相當于 vue-cli 的腳手架，一行命令生成簡單的 demo 項目。用戶可以基于這個 demo 進行開發，省去了啟動項目前繁瑣的配置。
2. 編譯打包：原生開發小程序缺失了許多能力，比如 LESS、SASS。很多用戶面對這個問題都是做一個簡單的 Gulp 編譯。WePY 自帶了編譯打包能力，想用 LESS、SASS、NPM 等可以直接使用 WePY 的打包工具輸出小程序可以運行的代碼。
3. 核心庫：核心庫類似 Vue、React 等。WePY 核心庫包含一些簡單的 API 封裝幫助處理一些事情。
4. 特性與優化：開發上，WePY 提供了一些語法糖，可以簡單方便的實現一些復雜功能。性能上，小程序本身的性能有一些問題，WePY 把性能上的問題抹平了，開發者不用關心性能這部分。
5. 復用與擴展：復用方面，原生小程序使用 npm 資源需要將相對應的資源下載并放到代碼目錄中，利用 WePY 可以直接安裝 npm 包并使用。擴展方面，在編譯過程中，可以隨意添加和擴展編譯手段，比如 LESS、SASS、編譯插件等。
6. 多端：利用 WePY 可以將一份代碼運行在小程序、H5 等端。

WePY 的規劃

16年8月參加小程序內測，10月份開(kai)(kai)始著手代碼轉換(huan)相關(guan)的(de)工(gong)作。在不停的(de)迭代中，我(wo)發(fa)現還有(you)很(hen)多(duo)事情可(ke)以(yi)(yi)做。比如可(ke)以(yi)(yi)將相關(guan)的(de)工(gong)作抽象出來提供給其它開(kai)(kai)發(fa)者(zhe)。于(yu)是在11月我(wo)對(dui)代碼進行(xing)了(le)重(zhong)(zhong)構，將 Gulp 編譯部分拋棄重(zhong)(zhong)寫并于(yu) Github 開(kai)(kai)源1.1版(ban)本。

開源(yuan)之后有很多人關(guan)注到(dao)這個項目，說明還是有不少人遇到(dao)了相(xiang)應的(de)問(wen)題。因(yin)此(ci)我做了更加(jia)具(ju)體(ti)的(de)優化，在(zai)1.1版本(ben)上(shang)又一(yi)次重構，把編譯(yi)流(liu)程抽(chou)象，提出(chu)了編譯(yi)器和插件兩(liang)個概念，方便用(yong)戶進(jin)行(xing)擴展。

17年1月份發布1.4版本，對(dui)整個開(kai)發流程和開(kai)發者使用框架時的體驗進行了(le)更多優化，包括性能優化等。

1.6 版本開始考慮(lv)多(duo)端問題：小程序(xu)一套代(dai)碼(ma)多(duo)端復用。

17年(nian)11月左右(you)，小程序推(tui)出了(le)原(yuan)(yuan)生組(zu)件(jian)。WePY 本(ben)身(shen)就是為了(le)解(jie)決小程序組(zu)件(jian)的問題，原(yuan)(yuan)生組(zu)件(jian)發布之后，WePY 的使用場景就沒(mei)有以前(qian)那么強了(le)，所以我(wo)開始思考， WePY 需要做一(yi)個完全重(zhong)構的版本(ben)。

18年2月份(fen)啟動(dong)了該重構版本，這(zhe)個(ge)版本主(zhu)要是(shi)(shi)為了解決小程序(xu)原生組件相(xiang)關的問題，是(shi)(shi)一個(ge)全新的重構版本。但由于各種原因，這(zhe)個(ge)版本還(huan)沒有(you)正式公布。敬(jing)請期(qi)待！

WePY 的實現原理

接下(xia)來我會(hui)講一下(xia) WePY 在技(ji)術上的(de)實現(xian)原理。

WePY 解決的問題

任何一個項(xiang)目都是(shi)發現(xian)問(wen)(wen)題，解決問(wen)(wen)題的過程，WePY 要解決的問(wen)(wen)題就是(shi)：

1. 組件化開發：小程序原生組件出現之前，小程序沒有很好的組件化開發模式。比如我自己實現了一套 dialog，別人想使用的時候可能要把我的代碼拷貝一份。實現了組件化之后，我只要把這個組件給他就好了。
2. npm 資源：Web 發展至今，npm 庫上有非常龐大的資源。但是原生小程序沒有使用 npm 資源的能力，WePY 提供了這個功能。
3. 前端工程化：前面提及的打包構建部分
4. 性能優化
5. 友好的開發體驗：體驗優化
6. 跨平臺支持：多端這部分

總的來說(shuo)，WePY 解決的問(wen)(wen)題(ti)就是(shi)開(kai)發中(zhong)遇(yu)到(dao)的痛點(dian)問(wen)(wen)題(ti)。

WePY 的架構

上(shang)面是我寫(xie)的(de)(de)兩個核(he)心(xin)的(de)(de)部分(fen)(fen)(fen)：CLI 以及(ji) Core。Core 通過(guo) CLI 編(bian)(bian)譯，生(sheng)成小(xiao)程序(xu)(xu)(xu)端(duan)運(yun)(yun)行的(de)(de)代碼。CLI 部分(fen)(fen)(fen)又(you)分(fen)(fen)(fen)為 wepy、wepy-web ，分(fen)(fen)(fen)別負責(ze) wepy 的(de)(de)編(bian)(bian)譯和(he) wepy-web 的(de)(de)編(bian)(bian)譯。其上(shang)又(you)分(fen)(fen)(fen)為編(bian)(bian)譯器(qi)和(he)插件(jian)(jian)(jian)兩部分(fen)(fen)(fen)，編(bian)(bian)譯器(qi)涉及(ji)到目(mu)前主流的(de)(de)預處理(li)器(qi)，類(lei)似 Webpack 的(de)(de) loader 。插件(jian)(jian)(jian)是在編(bian)(bian)譯之后要(yao)做的(de)(de)事情，類(lei)似于 Webpack 的(de)(de) plugin。Core 部分(fen)(fen)(fen)分(fen)(fen)(fen)為 wepy 核(he)心(xin)庫、小(xiao)程序(xu)(xu)(xu)核(he)心(xin)庫和(he) wepy-web 核(he)心(xin)庫。wepy-web 核(he)心(xin)庫比小(xiao)程序(xu)(xu)(xu)多(duo)了 wepy components 和(he) wepy API 。小(xiao)程序(xu)(xu)(xu)本(ben)身(shen)的(de)(de)一些內置組件(jian)(jian)(jian)，比如彈窗組件(jian)(jian)(jian)，想要(yao)多(duo)端(duan)運(yun)(yun)行都需(xu)要(yao)封(feng)裝起來放在 wepy components 。小(xiao)程序(xu)(xu)(xu)原生(sheng) API 需(xu)要(yao)通過(guo) wepy API 封(feng)裝。

web 本身還分很多平臺種(zhong)類，比如 browser、微(wei)信(xin) h5、QQ h5，這(zhe)些都需(xu)要分別適配(pei)，所(suo)以 wepy-web 之(zhi)上(shang)是一個適配(pei)層。

整個 Core 之上(shang)，是用戶(hu)封裝的一些(xie)組件(jian)，比如上(shang)報、異(yi)步。還有一些(xie)功能組件(jian)，比如用戶(hu)做的彈窗、toast、imageloader 等。

縱觀整個 WePY，我的代(dai)碼會通過 CLI 基于 Core 輸出(chu)小(xiao)程序端運行的代(dai)碼。

WePY 的編譯過程

WePY 本身(shen)定義了(le)一個(ge)(ge)文件后綴(zhui) .wpy 。編譯(yi)時(shi)將該文件解析(xi)并拆分為 Style、Template、Script。拆分時(shi)，會解析(xi)并記錄組件關系(xi)，包括事件、引用(yong)(yong)等。每個(ge)(ge)節點(dian)的(de)信(xin)息都會被記錄，在(zai)注入(ru)時(shi)生(sheng)成到 JS 中，在(zai) JS 中就可以知道組件關系(xi)并進行調用(yong)(yong)。生(sheng)成完(wan)之(zhi)后進入(ru)到 plugin，plugin 是(shi)用(yong)(yong)戶自定義的(de)，需要進行圖片壓縮(suo)(suo)、JS 混(hun)淆(xiao)、wxml 壓縮(suo)(suo)等處理。依次(ci)做完(wan)這些處理之(zhi)后才(cai)會得到可以在(zai)小(xiao)程(cheng)序中運(yun)行的(de)代碼。

以上就是 WePY 的整個編譯(yi)過程。

多端的實現

在實現(xian)多端方面(mian)，面(mian)臨著(zhu)以(yi)下問(wen)題：

• 開發模式

  小程(cheng)序開(kai)(kai)發(fa)模(mo)式(shi)自(zi)成(cheng)一派，與現有開(kai)(kai)發(fa)模(mo)式(shi)都不相同。好在使(shi)用 WePY 開(kai)(kai)發(fa)時(shi)，WePY 使(shi)用的是類 Vue 的開(kai)(kai)發(fa)語法(fa)，跟 Vue 開(kai)(kai)發(fa)模(mo)式(shi)很貼近(jin)，所以開(kai)(kai)發(fa)模(mo)式(shi)問題借助 WePY 非常好解決。

• 標簽與(yu)樣式

  小程序與 H5 的(de)標簽不(bu)一(yi)樣，但是(shi)可以直接(jie)做一(yi)些簡單(dan)的(de)轉換(huan)處理。比(bi)如 <view> 轉換(huan)為 <div> 。樣式上小程序有一(yi)個 rpx 單(dan)位，在 750 px 的(de)情況下直接(jie) /2 將 rpx 轉為 px。

• 模版語法

  小(xiao)程(cheng)序有自己的(de)模版(ban)語(yu)法，比如 <wx-if> ;等，解(jie)析(xi)時可以做簡單的(de)轉換。

• 模塊化

  小程序原(yuan)生可(ke)(ke)以使用 require ,但是H5不可(ke)(ke)以。好在有很多工具值得(de)借鑒(jian)，比(bi)如 webpack,browserify。

• 內置(zhi)組件及(ji)內置(zhi) API

  WePY 本身使(shi)用的(de)(de)是(shi)類 Vue 的(de)(de)語(yu)法，要轉換為 Vue 運行在 Web 端(duan)的(de)(de)話，內(nei)置組(zu)件直(zhi)接使(shi)用 Vue 的(de)(de)形式編寫，使(shi)用時直(zhi)接引入這個 Vue 組(zu)件。內(nei)置 API 使(shi)用 WePY 提供的(de)(de) JSSDK 去模擬微信端(duan)、H5等提供的(de)(de) API。

因此，多(duo)端(duan)實(shi)現(xian)完全可行。我們的(de)一些項目完全利用(yong) WePY 實(shi)現(xian)多(duo)端(duan)。

生態

左邊是(shi)(shi)在(zai) Github 上看(kan)(kan)到的(de)一些 UI 庫，大家在(zai)使(shi)用(yong) WePY 開發(fa)的(de)時候(hou)可以直接利用(yong)這些 UI 庫進行二次開發(fa)。右邊是(shi)(shi)網上收(shou)集到的(de)開發(fa)資源(yuan)，包括開發(fa)組件、第三(san)方模塊等(deng)。Github 上 WePY 關鍵字搜(sou)索結果有900多頁。從用(yong)戶反饋來看(kan)(kan)，用(yong)戶選擇(ze) WePY 的(de)一個原因也是(shi)(shi) WePY 誕生(sheng)的(de)時間(jian)長，生(sheng)態比較完善。

WePY 的規劃

現有問題

WePY 目(mu)前存在的(de)核(he)心問題是

• 靜態組件編譯

  WePY 項目做的比較倉促，花了(le)(le)大概一個(ge)多月就上線了(le)(le)。最開始只是(shi)為了(le)(le)解(jie)決組(zu)(zu)件(jian)(jian)化的問題。因此(ci)它采用了(le)(le)靜(jing)態組(zu)(zu)件(jian)(jian)編(bian)譯這(zhe)套方案，在編(bian)譯組(zu)(zu)件(jian)(jian)時(shi)，直接將我寫的組(zu)(zu)件(jian)(jian)進行靜(jing)態替換(huan)，將我寫的組(zu)(zu)件(jian)(jian)注入(ru)到頁面中，做了(le)(le)一些隔離相關的事情。這(zhe)導致動(dong)態 repeat 時(shi)會出現(xian)比較嚴重(zhong)的 BUG。這(zhe)是(shi)設計上的缺陷，也是(shi)急需解(jie)決的問題。

• 語法解析

  xml 的解(jie)(jie)(jie)(jie)(jie)析(xi)用了一(yi)個存在問(wen)題的庫(ku)，導(dao)致 xml 解(jie)(jie)(jie)(jie)(jie)析(xi)時(shi)經常出(chu)錯(cuo)。js 的解(jie)(jie)(jie)(jie)(jie)析(xi)設(she)計(ji)之初沒有考慮(lv)用語法(fa)樹(shu)解(jie)(jie)(jie)(jie)(jie)析(xi)，而(er)是(shi)使用正(zheng)則進行解(jie)(jie)(jie)(jie)(jie)析(xi)。因為(wei)目前僅(jin)涉及解(jie)(jie)(jie)(jie)(jie)析(xi)和語法(fa)注入，實現起(qi)來都比較簡單，所以沒有考慮(lv)用 AST 語法(fa)樹(shu)進行解(jie)(jie)(jie)(jie)(jie)析(xi)，導(dao)致用戶(hu)沒有按照規(gui)范寫的一(yi)些代碼在解(jie)(jie)(jie)(jie)(jie)析(xi)時(shi)會出(chu)現錯(cuo)誤。

• 類(lei) Vue 語法

  從用戶的反饋來看，大家更希望用 Vue 的語法(fa)而不是(shi)類 Vue 語法(fa)。這兩個之(zhi)間(jian)還(huan)是(shi)有一(yi)些差異的。

• 數據綁定性能優化

  數(shu)(shu)據(ju)綁定時做了一些優化(hua)和處理。但這些優化(hua)和處理是(shi)通(tong)過(guo)臟(zang)數(shu)(shu)據(ju)進行的(de)，幫助用(yong)戶減少 setDate 的(de)次數(shu)(shu)。但是(shi)后來再看，這塊還是(shi)有可以優化(hua)的(de)空間。

• 錯(cuo)誤處理機制

  目前 WePY 的錯誤處(chu)理還比較簡單，沒(mei)有一個(ge)通用的錯誤處(chu)理機制(zhi)。用戶在使用和(he)編(bian)譯時(shi)的報錯很難追溯(su)和(he)定位(wei)。后面(mian)希望能做到(dao)在報錯時(shi)可以定位(wei)到(dao)報錯的文件和(he)代碼。

• 測試用例覆蓋度(du)

  WePY 目(mu)前只(zhi)有核心庫被(bei)測試用(yong)例覆蓋。CLI 部分很復雜沒有做測試用(yong)例覆蓋。這導致目(mu)前大(da)部分問(wen)題都和(he) CLI 相關。在下一個版(ban)本要全(quan)部被(bei)測試用(yong)例覆蓋。

編譯

上圖是2.0版本編(bian)譯部(bu)分的(de)對(dui)比。左邊是 1.0 的(de)編(bian)譯，右(you)邊是2.0正在做的(de)事。前(qian)面有講(jiang)到(dao)1.0的(de)編(bian)譯是把.wpy 文(wen)(wen)件(jian)(jian)(jian)放到(dao) CLI 中進行編(bian)譯。CLI 本身涉(she)及編(bian)譯器(qi)和插件(jian)(jian)(jian)。在2.0中，將文(wen)(wen)件(jian)(jian)(jian)編(bian)譯修改為了入口編(bian)譯，從 App 入口，通過(guo)(guo) CLI 自(zi)動解析(xi)依賴，CLI 中也只有插件(jian)(jian)(jian)，所有的(de)核心功(gong)能都將通過(guo)(guo)插件(jian)(jian)(jian)實現。最(zui)后生成(cheng)的(de)除了小程序文(wen)(wen)件(jian)(jian)(jian)，還(huan)有 Vendor 文(wen)(wen)件(jian)(jian)(jian)（Vendor 文(wen)(wen)件(jian)(jian)(jian)是指所有的(de) npm 包都會打包到(dao)這個文(wen)(wen)件(jian)(jian)(jian)內）、資源文(wen)(wen)件(jian)(jian)(jian)以及自(zi)己引(yin)用的(de)模塊(kuai)的(de)文(wen)(wen)件(jian)(jian)(jian)。

插件化

編譯(yi)的(de)(de)(de)核(he)心部(bu)分是(shi)參考(kao) Webpack 做(zuo)的(de)(de)(de)插件(jian)化(hua)編譯(yi)。插件(jian)化(hua)的(de)(de)(de)概念參考(kao)我上(shang)面(mian)做(zuo)的(de)(de)(de)圖：固定(ding)(ding)一(yi)塊板子，板子上(shang)有(you)固定(ding)(ding)數量的(de)(de)(de)掛(gua)(gua)鉤(gou)(gou)(gou)，每個(ge)掛(gua)(gua)鉤(gou)(gou)(gou)都可以(yi)掛(gua)(gua)不(bu)同(tong)的(de)(de)(de)東西。每個(ge)掛(gua)(gua)鉤(gou)(gou)(gou)放什么不(bu)清楚，但是(shi)每個(ge)掛(gua)(gua)鉤(gou)(gou)(gou)都可以(yi)實現不(bu)同(tong)的(de)(de)(de)功能。我只需要規定(ding)(ding)編譯(yi)的(de)(de)(de)流程，通過(guo)在掛(gua)(gua)鉤(gou)(gou)(gou)中寫不(bu)同(tong)的(de)(de)(de)內容實現整個(ge)編譯(yi)流程。所以(yi)整個(ge)編譯(yi)過(guo)程變(bian)為：配置初始化(hua):arrow_right:核(he)心編譯(yi):arrow_right:輸出(chu)文件(jian)。

插(cha)(cha)件化可以(yi)提供更高的(de)擴展性和(he)可復用(yong)(yong)性。所有的(de)核(he)心功(gong)能(neng)都依(yi)賴插(cha)(cha)件進行。用(yong)(yong)戶覺得某個功(gong)能(neng)不合適的(de)時候，完全可以(yi)自己(ji)寫一個插(cha)(cha)件替換(huan)掉(diao)核(he)心功(gong)能(neng)。用(yong)(yong)戶可以(yi)對編譯(yi)的(de)任(ren)何一個環節進行修改。

數據綁定v1

v1 的數(shu)(shu)據(ju)(ju)綁(bang)定：在初始化的時候對(dui)數(shu)(shu)據(ju)(ju)進行深拷貝做(zuo)數(shu)(shu)據(ju)(ju)備份。每個流(liu)程都會(hui)預置 apply 動作，比如(ru)有一個點擊(ji)事件，點擊(ji)事件對(dui)數(shu)(shu)據(ju)(ju)進行修改后(hou)進入(ru)(ru)到 apply 流(liu)程，在 apply 流(liu)程中進行深比較得到臟數(shu)(shu)據(ju)(ju)，臟數(shu)(shu)據(ju)(ju)最終(zhong)進入(ru)(ru)到 setDate 中。

右邊(bian)是比(bi)較簡單易(yi)懂的圖：小明(ming)對文(wen)件 B 進(jin)行修改(gai)得到 B+,老(lao)師將 B+ 和 B 進(jin)行對比(bi)，得到修改(gai)的數據。這是一個同步流(liu)程。當(dang)小明(ming)叫小紅(hong)修改(gai) C 文(wen)件時，如果老(lao)師不再，需(xu)要小紅(hong)主(zhu)動叫老(lao)師對 C 文(wen)件進(jin)行對比(bi)。即手動調用 apply 流(liu)程。

數據綁定v2

2.0 使用了 Vue 的數(shu)據綁定機制。在(zai)初始化時(shi)生成(cheng) Render Watcher，每個數(shu)據初始化時(shi)都會添加 observer。修(xiu)改(gai)數(shu)據時(shi)記錄修(xiu)改(gai)的 key-path 并(bing)加入隊列中(zhong)，所有的修(xiu)改(gai)動作都會觸發 Watcher。在(zai)一個 nextTick 時(shi)間內會清空隊列，并(bing)在(zai) Render Watcher 中(zhong)進行 setDate。setDate 環節根據記錄的 key-path 進行 setDate。

相比小(xiao)明(ming)和老師的(de)(de)故事：小(xiao)明(ming)在修(xiu)(xiu)改(gai)(gai)文件時(shi)會(hui)主動記(ji)錄(lu)修(xiu)(xiu)改(gai)(gai)的(de)(de)內容(rong)并發起通(tong)知，小(xiao)紅的(de)(de)操作方式與小(xiao)明(ming)一致。當老師收(shou)到通(tong)知時(shi)，根(gen)據小(xiao)明(ming)、小(xiao)紅的(de)(de)修(xiu)(xiu)改(gai)(gai)記(ji)錄(lu)對修(xiu)(xiu)改(gai)(gai)的(de)(de)內容(rong)進(jin)行 setDate 的(de)(de)處(chu)理(li)。

 這種(zhong)優化方(fang)式不需要手動調(diao)用 apply,也不需要關心異步流程(cheng)。

質量

第二(er)個版本會先在內(nei)部(bu)項目(mu)運用，內(nei)部(bu)實踐之后(hou)沒有問題再開源。另外2.0版本測試(shi)用例覆蓋度(du)要完全覆蓋。

開源經驗分享

規范

如(ru)何保證開源項目(mu)的質量？

第一(yi)是(shi)文檔(dang)規(gui)范。Readme 部分要(yao)言簡意賅的講明這個(ge)項(xiang)目(mu)能做什么，一(yi)個(ge)簡單的示(shi)例說明如何啟動項(xiang)目(mu)。Readme 要(yao)簡潔(jie)，大家一(yi)眼能看到他想要(yao)的東西(xi)。

第(di)二(er)是 CI。將對應的(de)狀態(tai)放(fang)在(zai) Readme，讓開發者可以更安心的(de)使用這個項目。

第三是(shi) license。

還有(you) contributer 文(wen)檔，代碼規范、Git 規范等。

測試使(shi)用了(le)(le) Mocha 和 Istanbul，集成使(shi)用了(le)(le) TravisCI，部署使(shi)用了(le)(le) npm 和 lerna。

推廣運營

推廣運營(ying)方(fang)面主(zhu)要靠自己發文章(zhang)，做(zuo)外鏈(lian)。另(ling)外我在公眾號和微信(xin)群推了自己的文章(zhang)。微信(xin)群做(zuo)了一個(ge)機器人放入群碼(ma)。

還做(zuo)了文(wen)檔(dang)(dang)監(jian)控，官方文(wen)檔(dang)(dang)修改(gai)(gai)之后，我(wo)(wo)可以第一(yi)時間知道官方文(wen)檔(dang)(dang)都修改(gai)(gai)了什么。以及(ji)監(jian)控報告，每天(tian)都會(hui)給我(wo)(wo)的微信推送(song)今(jin)天(tian)項目有(you)多少 star 、多少 issue 。