經驗總結--個人小程序開發和進化之路

時間 2019-11-17

原文原文鏈接

前言

從接觸小程序開始，到如今大大小小作了差很少有五六個小程序項目了，小項目的只有幾個頁面，大的項目有幾十個頁面。此篇文章是對以前項目的一個總結，項目的腳手架，開發框架和後期的優化是一個逐漸進化完善的過程，若是你打算開發小程序或者已經在開發小程序，相信這些經驗對你會有必定的幫助。javascript

腳手架

小程序開發者工具能夠直接編寫小程序的，可是開發工具就像武士手中的劍，多年磨鍊，已經達到人劍合一了，忽然換把武器，那勢必影響殺敵效率，因此使用本身熟悉的開發工具仍是頗有必要的。html

本人所在的公司基本都是中小型公司，項目開發週期都很短，前期的準備工做最多也就幾天時間，因此本身去擼一套腳手架而後用於項目開發，難度比較大，在網上找優質的資源是最好的選擇。前端

大佬justjavac的開源項目微信小程序開發資源彙總，涵蓋了大量的優質小程序開發資源，在此推薦一波。vue

固然，腳手架的選擇也是視項目而定的，若是隻有幾個頁面的項目，搞一套很重的工具未免有點多此一舉了。咱們的作法是小項目，直接擼，大點的項目選用網絡上的優質資源+本身改寫。java

17年的電商項目，模塊很少，採用的腳手架比較簡單，使用gulp監聽文件改動，實時編譯，支持ES6+語法。

腳手架地址

18年中旬的電商項目，到了新的公司，當時選用了WePY進行開發，特性簡單介紹下：

類Vue的開發風格
組件化開發（WePY出來的時候，小程序還不支持組件）
支持加載外部NPM包(小程序原生也支持)
使用babel編譯，支持ES6/7的語法
針對原生API進行優化

詳細介紹請點擊WePY文檔進行查看，後續框架選擇上也會提到，差點被這框架害慘了。react

最近的一個地產項目，也是下一個項目打算使用的，weapp-start，上文提到的小程序開發資源彙總中也有提到，特性以下：

支持 npm 包引入
支持 promise, async/await 等最新語法
支持多種編譯器，如 pug/less/stylus
支持 ESlint
支持本地 mock 數據
支持一鍵生成項目，組件模版
支持發佈前資源壓縮
支持自定義插件
多種工具，加速開發

項目的地址爲weapp-start，其中weapp-plugin-require（分析依賴，導入第三方 npm） ，存在問題，window操做系統會出現路徑錯誤，我已修復，並給做者提了PR，但做者並無修復這個問題，若是有同窗要用到這個腳手架，請下載我修改好的文件進行替換，下載地址。webpack

另推薦我根據weapp-start搭建的環境，目錄結構爲：git

├── README.md                 // 說明文檔
├── dist                      // 編譯後的代碼，用小程序開發工具打開此文件夾
├── mock.js                   // 模擬數據的文件
├── package-lock.json
├── package.json
├── project.config.json       // 項目配置文件
├── src                       // 項目代碼都在這個文件夾下
│   ├── app.js                // 等同於小程序根目錄下的app.js
│   ├── app.json              // 等同於小程序根目錄下的app.json
│   ├── app.wxss              // 等同於小程序根目錄下的app.wxss
│   ├── assets                // 項目中使用到的靜態資源
│   │   └── images
│   │       ├── example
│   │       └── tab
│   ├── components            // 公用的組件
│   ├── page                  // 存放小程序的各個頁面文件
│   │   ├── example           // example 頁面
│   │   │   ├── components    // example頁面中的組件
│   │   │   ├── index.js
│   │   │   ├── index.json
│   │   │   ├── index.wxml
│   │   │   ├── index.wxss
│   │   │   ├── services      // example頁面中接口
│   │   │   ├── template      // example頁面中的模板
│   │   │   └── wxs           // example頁面中的wxs文件
│   │   ├── globalStore.js    // 全局共享的數據
│   │   └── test
│   │       ├── index.js
│   │       ├── index.json
│   │       ├── index.wxml
│   │       └── index.wxss
│   ├── template              // 公用的模板
│   └── utils                 // 公用的方法或工具
│       ├── config.js         // 全局的一些配置信息
│       ├── create.js         // 狀態管理插件
│       ├── mitt.js           // 狀態管理插件
│       ├── obaa.js           // 狀態管理插件
│       ├── util.js           // 公用方法
│       ├── wxRequest.js      // 封裝的小程序請求數據方法
│       └── wxapi.js          // 對小程序api進行Promise封裝
└── weapp.config.js           // 對腳手架的配置文件
複製代碼

項目地址爲點擊查看，以爲有用的請Star或者fork喲。github

固然，網上也有不少優秀的腳手架，你們能夠根據本身的須要選擇喲。web

小程序開發框架

17年的項目並無使用開源的框架，直接使用原生小程序寫的，開發過程印象中並無不少的坑，只記得當時用到了一個富文本的插件，wxParse，如今已5000多個Star了，雖然如今小程序有了富文本組件rich-text，但在最近的項目中仍是用了這個插件，由於後端的兄弟說，他們不能將html轉成rich-text須要的數據格式，後端是java的，有使用這個組件的同窗，麻煩下面留個言，我要去鄙視後端一下。

前文提到本身在項目開發過程當中使用過WePY框架，那麼下面我就簡單列一下如今比較火熱的三大小程序框架WePY，mpvue和Taro的特性，而後着重說下WePY：

mpvue（美團）

完全的組件化開發能力：提升代碼複用性
完整的 Vue.js 開發體驗
方便的 Vuex 數據管理方案：方便構建複雜應用
快捷的 webpack 構建機制：自定義構建策略、開發階段 hotReload
支持使用 npm 外部依賴
使用 Vue.js 命令行工具 vue-cli 快速初始化項目
H5 代碼轉換編譯成小程序目標代碼的能力

taro （京東）

React 語法風格
支持使用 npm/yarn 安裝管理第三方依賴。
持使用 ES7/ES8 甚至更加新的 ES 規範，一切均可自行配置。
持使用 CSS 預編譯器，例如 Sass 等。
持使用 Redux 進行狀態管理。
持使用 Mobx 進行狀態管理。
程序 API 優化，異步 API Promise 化等等。

WePY （騰訊）

上文已列出，此處再也不贅述

三大框架分別是國內三家大佬的前端團隊產物，印象中mpvue和taro都是18年下半年出來的，WePY出來的最先，幾乎和小程序同步。

mpvue擁抱了vue，taro擁抱了react，WePY握住了vue的手，mpvue和taro都沒有用過，咱們只是開發個小程序，不用作到H5和RN共用一套代碼，因此18年中開發的一個電商小程序選擇了WePY，畢竟騰訊的產物，親兒子。

後來瞭解到，是騰訊的兒子沒錯，不過是養子，WePY原本是騰訊內部一員工的我的項目，後來騰訊團隊看這個項目不錯，就由官方來維護了，由此帶來了一些問題，曾在掘金看到過對WePY做者的專訪（好像是專訪，文章我找不到了），做者本身也認可，WePY前期的一些核心代碼存在的缺陷，後期很難修復了，像髒檢查機制，聽說2.0會有很大的改變。

貼一張WePY其中的一個Issue，咱們當時的心情和他是同樣同樣的，不過咱們不用重構了，項目死掉了，哈哈哈哈（悲涼的笑）

本身曾經寫過一篇wepy+weappx開發小程序遇到的坑以及解決方案，文中列舉了開發過程當中遇到的一些問題和解決方式，在此就不贅述了，想了解的同窗能夠點擊查看。

若是你要問我開發小程序選擇那個框架合適？我只能給出一個建議，根據需求來定，若是隻是單純的想作個小程序，就不要用框架了，小程序的語法目前已經很完善了，何須要去學習兩套語法呢，出了問題，又改不動他們框架，一句話歸納下就是，小程序原生有的問題他們確定有，原生沒的問題，他們可能給你造出來。

固然，若是有寫一套代碼適用H5和RN,那麼能夠考慮下mpvue和taro，做者更新很頻繁，有團隊維護，至於能不能提升效率，還得看需求，咱們如今是不會選用任何框架了，小程序已經玩的很熟，不必再折騰了。

小程序開發建議

在開發過程當中，咱們總結了一些感受比較好的開發實踐，在此奉獻一波，大佬別笑哈。

上文中腳手架第三項中貼出的目錄結構，是目前咱們以爲比較好的一種形式（參照umi項目的建議），按頁面組織代碼，將一個頁面所須要的內容放在同一個文件夾，方便往後的維護和有相似頁面開發時候的複製，存在公用組件的時候，放到外部的文件夾中，當一個項目大了之後，這種目錄結構，真的很方便。

組件的層級

組件的層級真的不能太深，2層最好，不能超過3層，以前項目有的封裝組件過分，層級太深，後期維護，根據數據傳遞一層層的去找代碼，簡直不要太爽（反話）。

狀態管理

目前小程序能用的狀態管理框架也是比較多的，Redux，Mobx，還有基於Redux二次開發的像weappx，都很好，在這推薦兩個本身用過和打算用的，使用過的weappx，打算用的omi-mp-create，項目比較小能夠不用，大項目仍是用上吧，都放到global中，很差維護。

頻繁setData的功能放到組件中

電商項目中，少不了相似倒計時這種功能的，像這種須要頻繁setData操做的功能，應該單獨放到一個組件中，爲啥呢？當你setData的時候，小程序會有一個遍歷監聽了data數據方法的過程，好比當你setData的時候，小程序wxs中的函數都會執行，在我上文提到本身的腳手架中有這個例子weapp-quick-start，感興趣的能夠測試一下。

使用WXS

小程序對js表達式的支持並非很好，固然，就算能夠，我也曾見過這樣的代碼

<block wx:if="{{drawgift.giftDetail.virtualGoods.length>1||((drawgift.giftDetail.realGoods.length>0||drawgift.giftDetail.couponGoods.length>0)&&drawgift.giftDetail.virtualGoods.length>0)}}">

複製代碼

把這些判斷的邏輯放到wxs中，統一維護豈不是美哉。還有一點，官方說在 iOS 設備上小程序內的 wxs 會比 javascript 代碼快 2 ~ 20 倍，因此，能用仍是要用起來的。