手把手教你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.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.這個時候你只需將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數據和接口.