手把手教你mockjs實際專案快速搭建

shotCat發表於2018-05-28
MockJS

1, 導讀

  • 1.1, 你會看到什麼?

    • 個人對mock的理解和應用場景.
    • 根據自己的實際工作專案,手摸手教你進行詳細的mockjs部署說明,而不是網上千篇一律照搬官網的簡單例項.看完之後直接就可以在自己的專案中進行使用,滿足正常的工作專案需求.
    • 這種學法與通過node的dev-server實現MockServer的優缺點.
    • 這種寫法的適用場景.
    • 最後說明下我的開發環境是vue2+elementUI2+nginx.

  • 1.2, 你不會看到什麼?

    • 你將不會看到對mock語法的逐個解說,這個官方文件已經詳細說明了.如果你對用法還是有很多疑點,那就在專案裡自己動手敲程式碼,去實踐!其實這樣比你在度娘和Google中搜尋要快得多,還印象更深!
    • 你將不會看到相關的mock框架的使用說明,例如json-server,easy-mock(這個還是很好用的!)等.

2, mockjs功能及適用場景

  • 2.1, mockjs的功能

    • 生產資料:通過mockjs提供的方法,你可以輕鬆地創造大量隨機的文字,數字,布林值,日期,郵箱,連結,圖片,顏色等.

    • 強大的攔截功能:mockjs可以進行強大的ajax攔截.能判斷請求型別,獲取到url,請求引數等.然後可以返回mock的假資料,或者你自己編好的json檔案.功能強大易上手.

  • 2.2, mockjs適用場景

    • 前後端分離:由於mockjs,前端的資料請求可以自給自足, "獨立" 於後端開發.在專案前期,前端可以專心於自己的前端展示,後端可以專心於自己後端的介面和資料處理.但前後端分離最怕的情況就是:前端自己玩自己的,後端也自己玩自己的.等到聯調時,發現介面完全牛頭不對馬嘴! 所以在開發時,前後端也要時刻保持溝通,及時確認最新的介面和資料結構. 這裡推薦使用swagger進行管理.
    • 方便單元測試:由於mockjs能產生很多隨機資料,模擬很多請求場景.所以可以保證單測一部分的真實性.但個人感覺還是不能完全替代真實的呼叫後端介面,後端處理的情況更加複雜.

3, mockjs專案實踐

  • 3.1, 安裝mockjs

npm install mockjs --save-dev
複製程式碼

  檢查mockjs是否安裝成功可以在package.json和package-lock.json中搜尋mockjs是否存在.

  • 3.2, 建立mock資料夾結構

mock資料夾結構
  因為實際專案需要mock的模組比較多,並且涉及到多人開發.所以我這裡採用瞭如圖所示的資料夾結構,這樣每個人可以根據自己所負責的模組分別存放mock資料.條理更加清晰,最重要的是資料不會混淆.如果你只需要mock幾個介面的資料,並且涉及到的開發人員較少,則可以完全使用官網教程上的,全部寫在一個mock.js上.

   各個檔案說明:

  mock:存放所有mock相關的檔案,建議放在根目錄,方便獲取和檢視.

  test:按專案模組分類存放對應的mock檔案.例如:device存放是device裝置模組需要的mock檔案.這裡test為存放這次演示所需的mock檔案.

  test-mock.js:mock主檔案.主要是mock資料,對攔截請求做處理.

  test-json.json:存放json格式的假資料.

  index.js:後面在main.js中引入的檔案.作用就是將所有模組的mock.js進行引入.

  utils.js:根據專案需求,將常用的模擬資料方法寫在裡面.方便模組mock假資料.

  • 3.3, test-json.json的說明.

  在定義介面階段,後端給出的介面文件裡就會有請求的介面和返回資料例項.這個時候雖然介面還不能訪問,但有了mockjs後,我們前端已經可以進行ajax請求.並且在json檔案中.將介面文件裡的資料例項,複製貼上,然後改一下就完成了最原始最簡單的資料實現.但如果是資料有特殊要求,數量很多,結構很複雜的,建議還是使用mockjs給出的方法來造資料.

swagger截圖
  這裡安利一下swagger,上圖截自swagger.這個時候你只需將ExampleValue下的資料例項進行復制.然後貼上到json檔案中,然後稍微修改一下就完成了.這裡我就不寫出來了,佔地方.其實在模擬簡單資料時,完全可以使用這種方法,沒必要使用mock的方法.

  • 3.4, test-mock.js的說明(重點)

import Mock from 'mockjs' //引入mock 
import testJson from './test-json.json' //引入上面建立的json假資料 
import utils from '../utils' //引入公用方法   
const res =function (opt) {
  //opt為ajax請求的選項集.包含url,type和body三個屬性
  // opt.url為請求的url.
 //opt.type為請求型別,例如get,post,delete
 //opt.body為請求的引數   
 
//1, 使用mock方法來造資料
  let mockData =Mock.mock({
  'code':0,
  'msg':'成功',
  'list|1-10':[{
  'id|+1':1
  }]
 });  
 let data=JSON.stringify(mockData,null,4);//將資料進行轉換    

//2, 對請求引數進行判斷
  let param=opt.body;//用param儲存請求的引數
  let result; //用result儲存對param校驗的結果    

//... 省略對param進行校驗的過程    

//3, 根據校驗的結果返回資料
  if(result===true){
  //此時校驗結果正確
  return data;
  //return testJson 也可以返回之前寫好的json檔案.自己看情況選擇.資料不復雜情況下,我是直接返回.json檔案.
  }else {
   return {
  //校驗錯誤,則返回錯誤提示資訊
     'msg':'請求引數錯誤'
  }
 } 
}   

Mock.mock(/devicemanage\/api\/pc\/dm\/device\/structure\/query\?token=/,'post',res)
//這裡使用mock()的函式寫法.這樣就可以獲取到請求的引數,這裡url是正則的寫法.
//Mock.mock(rul,rtype,function(opt))  
//rul:需要攔截的url.這裡有兩種寫法,一種是字串形式,例如:'/api/device'則表示只能攔截/api/device請求.但我們可能會經常需要在url上新增token等其他引數.
//這時就需要寫成第二種形式,正規表示式/api\/device/,這樣我們就能攔截所有包含/api/device的請求.這樣我們在進行ajax請求時,就可以直接編寫真實的url地址.
//rtype:表示需要攔截的ajax請求型別.例如:get,post,put,delete等.
//function(opt):響應資料的函式,其中opt已經在程式碼最上面進行了說明.

複製程式碼

  • 3.5, index.js的說明

import device from './device/device-mock' 
import event from './event/event-mock' 
import home from './home/home-mock' 
import log from './log/log-mock' 
import patrol from './patrol/patrol-mock' 
import test from './test/test-mock'
複製程式碼

  從上面的程式碼來看,這個檔案的作用很顯然,就是將分散的mock檔案集合起來.後面再新增新的mock檔案,都需要在這裡引入.

  • 3.6, utils.js的說明

  這個js檔案,就是存放你需要用到的公用方法(例如json格式轉換)和專案常用的mock資料(例如我司常用的裝置列表和組織結構).這裡我就不貼自己公司程式碼了.自己根據官方文件mock常用的資料並匯出.

  • 3.7, 在main.js中引入的說明

import mock from '../mock/index'
複製程式碼

  在main.js中引入也很簡單.只需要引入上面的寫好的index.js就可以了.到此你就已經完成了mockjs的專案實踐.趕緊跑一遍看看!

4, 為什麼我沒用自帶的dev-server搭建Mock Server?

  一句話概括就是暫時不適合該專案.下面列出幾條主要原因,僅代表個人觀點和在該專案情況下.如果你覺得有其他看法或者更好的建議和想法,歡迎評論指正.

  • 直接使用mockjs專案結構修改更少,語法書寫也更簡單.網上很多教程都是通過在dev-server上進行修改.然後通過proxyTable或者利用before鉤子進行攔截.但是我感覺還是很複雜,結構也不明顯,並且需要對express的語法和用法要有比較充分的瞭解,否則修改起來很容易報錯,也不是很安全.
  • 當你修改了mockjs後,網頁會自動重新整理,看到你mock的資料.如果你是在dev-server上修改的話,則需要重新跑一邊run dev.雖然你可以裝外掛,不用手動dev.但效率和方便程度上還是比不上自動重新整理的.
  • 請求攔截方面,mockjs優先順序最高.mockjs>nginx>dev-server.所以你可以使用Mock.mock()方法攔截任何你想攔截的請求而不需要擔心nginx或者其他代理.而當你使用dev-server進行攔截時,並且你也和我一樣,專案之前配置了nginx,則會比較麻煩.可能你還需要對nginx進行配置,避免攔截了dev-server的請求.然後重啟一遍服務,然後再run dev.後端介面完成後,你還得再改回去.(舉個例子:nginx攔截了/devices,但這次新增了一個介面路徑/devices/newApi你需要在dev-server上攔截.這時你就必須修改nginx的配置.)
  • mockjs提供的mock()方法,可以更簡單方便的限制請求型別並獲取請求引數.並以此返回對應的資料.並且還可以按自己喜好返回.json檔案或者是mock的資料.
  • 這種檔案結構其實也可以做到mock檔案的模組化管理,實現也不復雜.沒必要藉助dev-server進行模組化.

  這種寫法的缺點:

  • 由於mockjs是js層面,最先開始攔截.所以有時要注意不要和之前配置的代理衝突了.
  • 由於mockjs是完全立足於前端,所以如果後端介面變了的話,需要自己及時手動進行修改.

5, 適用場景

  • 5.1 適合:

  如果前端開發人員不多,只有四五個人.並且不存在跨地區合作的話.其實這種寫法已經可以滿足現階段mock需求.

  • 5.1 不適合:

  如果前端開發人員很多,存在跨地區合作,交流困難,後端介面需要頻繁修改的話.這種寫法並不適合!這時候推薦使用easy-mock.部署到本地內網後,就可以和其他前端後端小夥伴愉快地 共同維護mock資料和介面.

相關文章