別急著動手

把玩過小程序開發(fā)的朋友應(yīng)該都有一種直觀的認(rèn)識：

API 高度封裝，精簡

組件豐富，足以滿足日常需求

官方工具齊備，云端解決方案到位

顯然，微信團(tuán)隊以折損自由度的代價，輔之完備組件，配有一站式工具，換取傻瓜式的開發(fā)體驗(yàn)。

以此來博取開發(fā)者的青睞，甚至 “勾引” 零基礎(chǔ)的人來嘗鮮，以淡化人們對 WXML 這種全新的、封閉的 XML 拓展語言的抵觸心理。（人們理所當(dāng)然擁抱 H5 這種 W3C Web 標(biāo)準(zhǔn)規(guī)范，卻不一定愿意傾注時間和精力去學(xué)習(xí)一門 封閉式、非標(biāo)準(zhǔn)化的私家語言）

拋開其他不談，單就門檻而言，已經(jīng)將到極低。

這容易給人造成一種假象，即小程序沒有啥技術(shù)含量，所有的能力框架已經(jīng)給出，原本需要一個月周期的 Web 、 App，用小程序?qū)崿F(xiàn)大可縮短到 1 至 兩周。

讓這個結(jié)論成立，得滿足一個前提，即只負(fù)責(zé)功能的實(shí)現(xiàn)，不考慮可迭代性或可測性。

然而不可迭代亦不可測的應(yīng)用程序，我通常認(rèn)為那只能是玩具 Demo。

互聯(lián)網(wǎng)應(yīng)用程序從來不是一觸而就

生活里，工作中你所使用過的任意一款應(yīng)用程序，哪怕是功能極簡，哪怕是采用了某高大上框架開發(fā)，都離不開軟件層面的構(gòu)架設(shè)計、迭代計劃和各類測試。

言下之意，好上手是一回事，把東西做好則是另外一碼事。

so， 忘記小程序的便捷性吧，那只是個幌子。

正確認(rèn)識小程序開發(fā)

WXML，玩過 Vue 嗎？相似度高達(dá) 80%，玩過的話，掃下文檔就可以上手?jǐn)]個 Demo；

玩過 React 嗎？ 組件化思想和生命周期 Hook 函數(shù) 一樣一樣的，玩過的話，只需熟悉下新語法；

如果曾經(jīng)玩過 Angular， 簡要替換下，還是可以快速上手；

如果玩過 React Native，那么這只是一次平滑的遷移。

說到底，小程序的意識形態(tài)可以說是國人首創(chuàng)（人口福利造就了微信，張小龍的野望，讓 WXML 有了載體，不然這種只能跑在某 App 里的全家桶，誰會來玩呢？如果印度也有 “啊三信” 的話，小程序這種形態(tài)也是可以復(fù)制的）然而小程序的設(shè)計模式，實(shí)現(xiàn)原理，只是借鑒、沿襲了時下幾大趨勢：組件化，JS膠合。

只要是遵循組件化思想，總能從前端三大框架里找到影子，只要是 JavaScript 驅(qū)動，就可以復(fù)用狀態(tài)機(jī)概念：Redux

言下之意，號稱簡單易用的小程序，終究離不開 View 層的狀態(tài)與交互，數(shù)據(jù)流的綁定與控制。幸運(yùn)的是，這些都有現(xiàn)成的解決方案，不幸的是，你必須用這些解決方案，否則在產(chǎn)品的路上，要分分鐘失控。

現(xiàn)在來思考小程序的實(shí)現(xiàn)，該如何分工

業(yè)務(wù)邏輯、數(shù)據(jù)流控制 、靜態(tài)資源、類庫、工具函數(shù)和模版&通用組件應(yīng)該相對解耦。可以通過目錄結(jié)構(gòu)來直觀地分配。

• actions/

  • getRecords.js
  • getRecords.test.js
  • .....

• common/

  • constants.js
  • strings.js
  • apis.js
  • ......

• images/

  • logo.png
  • ......

• layouts/

  • home-list.wxml
  • ......

• libs/

  • redux.js
  • ......

• pages/

  • home/
  • me/
  • ......

• reducers/

  • home.js
  • me.js
  • ......

• utils/

  • getToken.js
  • getToken.test.js
  • formatDate.js
  • formatDate.test.js
  • ......

• app.js

• app.json

• app.wxss

我用了 Redux 所以會有 reducers 和 actions 目錄。 reducers 存放每個 page 對應(yīng)的邏輯分發(fā)和數(shù)據(jù)同步； actions 目錄存放每一次 View 的交互邏輯，這兩者是一一對應(yīng)的，熟悉 Redux 的一目了然。

common 目錄存放一些常量、字符串、API 資源 以便統(tǒng)一配置、調(diào)用。

layouts 目錄存放一些通用模板，或者說可復(fù)用的組件，遵循組件化思想，盡量不重復(fù)自己。

utils 目錄自然是放一些和主業(yè)務(wù)邏輯無瓜葛的通用工具函數(shù)。

其他目錄無需贅述，都是些基本的命名和用法，這里面沒有 test 目錄，整個項(xiàng)目的邏輯已經(jīng)被 Redux 解耦，所以我直接在 actions 目錄里寫一些功能測試，在 utils 目錄里寫單元測試，主要是引用方便吧，借鑒了 facebook 的 create-react-app 的做法。

說點(diǎn)和 Redux 相關(guān)的

Redux 是 React 生態(tài)圈的產(chǎn)物，一種類似 facebook 官方 flux 實(shí)現(xiàn)的狀態(tài)機(jī)小類庫， 但它適用于所有 JavaScript 驅(qū)動的前端框架；強(qiáng)調(diào) View 層皆狀態(tài)，一種狀態(tài)對應(yīng)一個 View。源碼很精簡，感興趣的可以去 Github Review。

這里想說的是，有些同學(xué)知其然不知其所以然，上來就用了各種封裝版 Redux，譬如 React 社區(qū)的 React Redux、React Router Redux；他們都很好用，但如果不明白 Redux 的實(shí)現(xiàn)原理就貿(mào)然使用，很容易迷失方向，喪失學(xué)以致用、舉一反三的能力，會在 React 上用 Redux，卻不能在 Vue、小程序里面用 Redux；其實(shí)作者也說了，直接 Redux 足矣，拓展封裝并不是必須的，只是方便（本人覺得并不方便）小程序也有 Redux 的拓展封裝，我沒有用，個人認(rèn)為，簡單的事情就應(yīng)該簡單辦，某些重復(fù)是必須的，因?yàn)槟菢涌梢宰屖虑楦逦?/p>

Redux 是函數(shù)式實(shí)現(xiàn)，強(qiáng)調(diào)不隨意改動數(shù)據(jù)，正常情況下只在開啟監(jiān)聽時初始化一次數(shù)據(jù)，此后所有的狀態(tài)都交由 Redux 來內(nèi)部處理即可（React 在最外層組件 set 一次 State 和開啟監(jiān)聽、小程序比較繁瑣，需要在每個 page 里分別 set 一次 Data 并開啟 subscribe 監(jiān)聽）。如此一來，項(xiàng)目的業(yè)務(wù)邏輯完全可以剝離出框架，起到高度解耦的作用，這為可迭代和可測試鋪平了道路。

說了那么多，曬下代碼吧，歡迎指正