Vue2+VueRouter2+Webpack+Axios建構項目實戰2017重制版（一）基礎知識概述

基礎概念論述

前後端分離開發模式

在若幹年以前，我們的web項目開發模式是如下的：

 1.設計師設計頁面初稿  2.前端工程師切成html+css+js的頁面  3.後端工程師拿到前端工程師的做好的頁面，利用模闆引擎或其他技術嵌套進後端代碼中，實作項目開發。

這種開發模式的缺點是，哪怕頁面出現一點點小的改變，也需要前端人員和後端人員同時協調開發，并且後端人員不能把全部全部精力放在業務流程以及資料邏輯等方面，還必須和前端人員一起來處理各種相容問題。開發效率不高，溝通繁瑣。

是以，我們推崇前後端分離的開發模式。

         1.設計師設計頁面設計稿

         2.前端工程師和後端工程師以及其他技術人員約定項目開發接口規範

         3.後端工程師按照約定接口規範開發相應接口

         4.前端工程師開發頁面，并對接後端接口（可能先期采用假接口）開發頁面

與不分離的開發模式相比，對前端技術人員的技術要求高了很多，原先隻需要會寫靜态頁面即可，但是現在必須了解如何對接接口，以及其他很多内容。很多十年以下的前端開發人員在學習這些新内容的過程中，崩潰了。

SPA

所有的前端人員都應該明白我們的頁面的url構成：

http://www.fengcms.com/index.html?name=fungleo&old=32#mylove/is/world/peac
           

如上的url由以下部分組成：

1.http://規定了頁面采用的協定

2.www.fengcms.com為頁面所屬的域名

3.index.html為讀取的檔案名稱

4.？name=fungleo&old=32 給頁面通過GET方式傳送的參數

5.#mylove/is/world/peace為頁面的錨點區域

前面四個發生改變的時候，會觸發浏覽器的跳轉或是重新整理行為，而更改url中的錨點，并不會出現這種行為，是以，幾乎所有的spa應用都是利用錨點的這個特性來實作路由的轉換。以我們的vue項目為例，它的本地url結構一般為以下格式。

http://localhost:8080/#/setting/task
           

可以明顯的看到我們所謂的路由位址是在#号後面的，也就是利用了錨點的特性。

以上了解是我的個人描述，不代表百分百符合标準答案，但這樣了解是沒有問題的。
           

RESTful風格接口

實際情況是，我們在前後端在約定接口的時候，可以約定各種風格的接口，但是，RESTful接口目前來說比較流行的，并且在運用中比較友善和常見的接口。

雖然它有一些缺陷，目前github也在主推GraphQL這種新的接口風格，但目前國内來說還是RESTful接口風格比較普遍。

并且，在掌握了RESTful接口風格之後，會深入的了解這種接口的優缺點，到時候，你自然會去想解決方案，并且在項目中實行新的更好的理念，是以，我這系列的博文，依然采用http://cnodejs.org/網站提供的RESTful接口來實戰。

了解程式開發的都應該知道，我們所做的大多數操作都是對資料庫的四格操作“增删改查”對應到我們的接口操作分别是：

    1.post插入新資料     2.delete删除資料     3.put修改資料     4.get查詢資料

注意：這裡我們約定，并非這些動作隻能幹這件事情。從表層來說，除get外的其他方法，沒有什麼區
           

别，都是一樣的。從深層來說包括get在内的所有方法都是一模一樣的，沒有任何差別。但是，我們約
           

定，每種動作對應不同的操作，這樣友善我們統一規範我們的所有操作。
           

假設，我們的接口是/api/v1/love這樣的接口，采用RESTful接口風格對應操作是如下的：

get 操作 /api/v1/love
           

擷取/api/v1/love 的分頁清單資料，得到的主體，将是一個數組，我們可以用資料來周遊循環清單

post 操作 /api/v1/love
           

我們會往/api/v1/love插入一條新的資料，我們插入的資料，将是JSON利用對象傳輸的。

put 操作 /api/v1/love/1
           

我們向接口送出了一個新的資訊，來修改ID為1的這條資訊

delete 操作 /api/v1/love/1
           

我們向接口請求，删除ID為1的這條資料

由上述例子可知，我們實作了5中操作，但隻用了兩個接口位址，/api/v1/love和/api/v1/love/1。是以，采用這種接口風格，可以大幅度

vue 是什麼，以及我們為什麼選擇 vue

在我們公司的實際拓展中，由于選擇架構時，

angular

 正在新舊交替，江山未穩，是以我們當時嘗試在兩個項目中引用不同的技術路線 

react

 和 

vue

 。

實踐證明，這兩個都是非常優秀的架構。但是同時也證明，在前端初學者的面前，

vue

 的學習成本明顯比 

react

 要低很多。

在同樣優秀，并且都能實作效果的情況下，我們選擇了 

vue

 技術架構。

是以，選擇的理由特别的簡單——隻是因為它更簡單！

好，

vue

 是什麼？

我不管官方的解釋是什麼，我的解釋如下：

為了實作前後端分離的開發理念，開發前端 SPA 項目，實作資料綁定，路由配置，項目編譯打包等一系列工作的技術架構

這裡，我們說的 

vue

 不僅僅是 

vue.js

 這一個檔案，而是圍繞 

vue.js

 配套的一系列的工具。就好比我們說的 

linux

 不僅僅是 

linux

 這個系統核心，而是包含了一整套外圍工具的完整系統。

具體如下：

1. vue.js

    核心，不解釋。

2. VueRouter2

    實作路由組織工具。

3. webpack

    項目打包以及編譯工具。

4. nodejs

    前端開發環境。

5. npm

    前端包管理器。

6. axios

    ajax 接口請求工具。

7. sass-loader

    和 

   node-sass

    css 預處理。

8. element

    基于 vue 的背景元件庫。

9. iview

    基于 vue 的另一套背景元件庫。

10. vue-cli

     vue 項目腳手架。一鍵安裝 vue 全家桶的工具。

其他還有很多，我們用到哪邊，說哪邊。

指令行的重要性

如果你依然沉浸在 

GUI

 的圖形界面中無法自拔，對于 

CLI

 指令行充滿恐懼或者敵視，那麼，現實會殘酷的告訴你，你落伍了。

雖然有很多項目在盡力的實作這些内容的可視化操作，例如 

iview

 的 

iView Cli

 ，我雖然肯定這些卓越的工程師做出的艱辛的努力，但是，不可否認的說，它也沒有徹底的拜托指令行。

并且，指令行

更好

更快

更強

更裝逼

是以，無論如何，你都不應該排斥指令行，還要積極的擁抱它，學習它，掌握它。

甚至，關注我部落格的同學可能會注意到，我前面自己甚至寫了很多的 

shell

 的相關部落格。要知道，我可是一個老前端工程師。這裡我不是顯擺我的資曆，而是客觀的評價自己，已經跟不上時代了。我所掌握的那些知識，是非常陳舊的。是以，隻有不斷的學習，才能不斷的提高自己。

我對你的建議如下：

1. 抛棄 

   windows

    作業系統，不管它是什麼版本的 

   windows

   。
2. 購買一台 

   macbook pro

    沒錢購買可以選擇 黑蘋果 ，可以參考我的系列博文 打造前端MAC工作站以及相關文章索引
3. 如果不是 

   photoshop

    的重度使用者，并且想要更深層次的掌握更多内容，請使用 

   linux

    系統。

   ubuntu

    作業系統還是比較簡單上手的。有一定 

   linux

    使用經驗的同學，建議使用 

   arch linux

    作業系統，新手不要嘗試，因為你一定安裝不上。
4. 除了使用 

   atom

    或 

   vscode

    這樣的現代編輯器，更推薦掌握 

   vim

    這樣基于

   cli

   的編輯器的基本使用。能用到什麼樣的層次，取決于你自己的需求，相關内容可以參考：世界上最牛的編輯器： Vim系列博文。

最後強調，别問我有關 windows 的問題，我很久沒用過 windows 系統，并且關于系統底層的問題，我根本就不知道如何解決。

我說的，你不一定要全部掌握或者了解。但一定要有一個起碼的概念。至少，知道我說的大概是一個什麼樣的玩意兒。

第一篇博文，基本沒有涉及到任何代碼的部分，但是下面，我們要開始幹活兒了。