【小程序】前端架構淺談

前些日子，在架構師帶領下，我和另外一個前端從零開始開發微信小程序。這是一個比較完整的項目開發，基於此項目，從如下幾個點，我對小程序的架構進行一些分析和介紹。

因爲本人能力有限，可能會有缺漏和錯誤，歡迎指出。

目錄

1. 項目介紹
2. 項目結構
3. 組件化開發
4. HTTP請求封裝
5. 文檔書寫
6. 總結

內容

 

1. 項目介紹

此是一個輕量的小程序，所有由原生小程序頁面組成。咱們將之劃分爲7個模塊，用戶、地址、優惠券、團購商城、訂單、紅包、退款。

項目初始是隻有產品原型，服務端開發、UI設計、前端開發是同步進行的。一開始，咱們是按照原型進行架構和頁面開發，UI設計圖和服務端接口後面陸陸續續提供出來的時候，咱們再進行修改，這邊會有一個很重要的，就是mock數據，這個會在後面講到。

 

2. 項目結構

項目結構主要分爲公用組件、圖片資源、頁面、數據格式處理、工具類。

 ├─ components（公用組件） ├─ images（圖片資源） ├─ libs（庫） │ ├─ mock.js（mock數據） │ ├─ sdk.js（接口封裝） ├─ pages（頁面） │ ├─ account（用戶相關） │ ├─ address（地址相關） │ ├─ coupon（優惠券相關） │ ├─ group（團購商城相關） │ ├─ order（訂單相關） │ ├─ redPackage（紅包相關） │ └─ refund（退款相關） ├─ service（數據格式處理） └─ utils（工具類） ├─ public.js └─ request.js ├─ components（公用組件） ├─ images（圖片資源） ├─ libs（庫） │ ├─ mock.js（mock數據） │ ├─ sdk.js（接口封裝） ├─ pages（頁面） │ ├─ account（用戶相關） │ ├─ address（地址相關） │ ├─ coupon（優惠券相關） │ ├─ group（團購商城相關） │ ├─ order（訂單相關） │ ├─ redPackage（紅包相關） │ └─ refund（退款相關） ├─ service（數據格式處理） └─ utils（工具類） ├─ public.js └─ request.js

 3. 組件化開發

你們都知道，組件化開發有不少好處。

• 組件複用，代碼量少，提升編譯速度。
• 組件的邏輯獨立，修改不會影響其它文件。
• 文件結構清楚，方便其餘人員的使用。

不過，若是組件設計不合理，業務拆分不對，也會形成重複代碼、組件通訊混亂和多工做量等問題。這個就須要項目開發者統籌全局，進行分析判斷。 因此，咱們研究了原型圖，分析其中的功能模塊和業務模塊，咱們將相同或可複用的模塊提取出來，放到全局組件庫下。同時，咱們將單個模塊也進行了組件化拆分，放在各自的模塊組件庫下。

在模塊中，咱們在頁面中也抽了一些邏輯相對獨立的代碼出來，寫成組件，有些是能夠複用，有些單純就是爲了頁面可讀性高些。複用舉例：在訂單詳情和訂單列表中，有關訂單的狀態及功能按鈕是一致的，咱們就將這一塊抽了出來，寫成behaviors。可讀性舉例：確認訂單頁中，選擇紅包的彈窗，就單獨寫成組件，只要將紅包選擇的最終結果傳給父組件就行，二者的邊界很清晰。

 4. HTTP請求封裝

微信小程序進行網絡通訊，要先設置域名，否則會提示不合法。設置域名的信息能夠在開發者工具-詳情-域名信息中看到。

使用wx.request能夠發起一個http請求

wx.request({
  url: 'test.php', // 開發者服務器接口地址 data: { // 請求的參數 x: '', y: '' }, method: 'GET', // HTTP 請求方法, 默認GET header: { // 設置請求的 header 'content-type': 'application/json', // 默認值 'cookie': 'token=' + token }, dataType: 'json', // 返回的數據格式, 默認json responseType: 'text', // 響應的數據類型, 默認text success (res) { // 接口調用成功的回調函數 console.log(res.data) }, fail () { // 接口調用失敗的回調函數 }, complete () { // 接口調用結束的回調函數（調用成功、失敗都會執行） } }) 

在平時項目使用中，咱們每每會對HTTP請求作一層封裝。

從圖中能夠看到，在自定義的SDK中封裝HTTPS請求的數據或MOCK的數據。在各個七個模塊的services中分派，而後再在頁面pages或者組件components中調用。

0. request模塊封裝，方便網絡請求。
1. 定義了一個名爲SDK的類，集成全部接口獲取的方法。
2. 在app.js中，經過new命令生成對象實例，將初始化後的sdk賦值globalData.API_SDK，方便項目中中調用。
3. Services中獲取globalData.API_SDK對象實例中的接口方法，並導出。
4. 在頁面中引用Services中的方法，並調用方法。

 

5. 文檔書寫

軟件開發文檔是軟件開發使用和維護過程當中的必備資料。它能提升軟件開發的效率，保證軟件的質量，並且在軟件的使用過程當中有指導，幫助，解惑的做用，尤爲在維護工做中，文檔是不可或缺的資料。

在項目中，咱們維護了兩份文檔，分別爲API文檔和組件README文檔。 在API文檔中，將每次SDK修改的內容都寫在文檔中，標註版本、時間、說明。並說明SDK接口的使用方式、傳參說明、API響應說明等。在README文檔中，則寫明目錄結構說明和全局組件說明。這樣，開發者就能夠經過文檔來比較方便的瞭解此項目的狀況。

 

6. 總結

在寫這個項目前，前端約定了小程序開發規範。明確了頁面、命名、樣式、行爲等規範。所以，在開發過程當中，咱們格外注意開發的風格，儘可能作到統一。

在原型出來之後，架構師根據原型圖進行了模塊和功能的劃分，明確了每一個人所作的開發內容，制定了前端開發排期。

在開發過程當中，由於UI圖還沒出來，咱們根據原型圖先進行了開發，後來在修改樣式的時候，感受仍是挺麻煩的。不過，雖然存在樣式返工問題，可是加快了後續的開發速度。

由於架構師封裝了所有的接口到SDK中，而且跟後端程序員約好了數據內容（全局統籌能力很強了，懂後端知識），咱們在對接的時候方便了不少，速度也快了不少。同時，在調試對接的時候，也修改了一些缺少的字段服務端沒有提供或者SDK沒有包的，這個咱們後續加進去的，在API文檔說明都有作修改內容說明（因此多人協做時，文檔真的很重要）。

這個項目前期很慢，後期很快。快到項目上線日期了，其實咱們有些接口還沒調完（測試已經在陸陸續續測試咱們已經寫好的模塊了），感受挺着急的，雖然上線日期定了，架構師說能夠延期的，不過很神奇的是，咱們如約上了。

這是我寫的第二個小程序的項目，是完整的整一個項目。前一個小程序項目只寫了一個小模塊，所以感受成長仍是挺大的。比較其餘以往的開發項目，相似vue、react、支付寶小程序，感受開發框架都是大同小異的，基本理念和流程都大體類似，只是開發語言或方法的實現有所差別。

 

----------------------------------------

小程序系列：

  前言

  項目結構

  生命週期

  請求與封裝

  數據綁定

  事件

  基礎使用： component使用 、 wxs使用 、 節點操做 、 頁面跳轉 、 緩存

  前端架構淺談

----------------------------------------