前言

2016年，我寫了一系列的 VUE 入門教程，當時寫這一系列博文的時候，我也只是一個菜鳥，甚至在寫的過程中關閉了程式碼審查，否則通不過校驗。

本來寫這一系列的博文只是為了給自己看的，但沒想到的是，這系列博文的點選量超過了2萬以上，搜尋引擎的排名也是非常理想，這讓我誠惶誠恐，生怕我寫的博文有所紕漏，誤人子弟。

再者，這一年的發展，VUE 專案快速迭代，看著我一年前寫的博文，很可能各種提示已經發生改變，對照著過時的資料，非常可能導致新手在學習的過程中產生不必要的困擾。

因此，本人決定，重寫這個系列的博文，力求以簡明、清晰、準確的圖文以及程式碼描述，配合 github 的專案開原始碼，給各位 VUE

基本理念

通過對接 cnode.js 的公開 api 的列表，以及詳情頁面，實現一個超小型的專案實戰，儘可能的掌握 vue 的專案入門的各項關鍵配置。 
本系列博文不涉及 vuex 的內容。因為這部分內容屬於比較高階的內容，並且在大多數中小型專案中是沒有多大用處的。所以情況是，大多數情況下，你並不需要 vuex。當你需要的時候，你應該有看懂官方文件的水平。如果你沒有看懂官方文件的水平，我說再多都是沒有什麼用的。並且在 vue 的入門文件中涉及這部分內容的話，會給新手徒增煩惱，所以本系列博文不涉及 vuex 的內容。

基礎概念論述

前後端分離開發模式

在若干年前，我們的 WEB

1. 設計師設計頁面設計稿
2. 前端工程師切成 html+css+js 的頁面
3. 後端工程師拿到前端工程師的做好的頁面，利用模板引擎或其他技術巢狀進後端程式碼中，實現專案開發。

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

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

1. 設計師設計頁面設計稿
2. 前端工程師和後端工程師以及其他技術人員約定專案開發介面規範
3. 後端工程師按照約定介面規範開發相應介面
4. 前端工程師開發頁面，並對接後端介面（可能先期採用假介面）開發頁面

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

我經常在我的部落格評論裡，看到這樣的評論 我艹，現在前端開發都這個樣子了。

時代發展浩浩蕩蕩，你我不進則退，我作為十三年前端開發經驗的人，也從13年開始，瘋狂學習 JS 相關內容，否則，真的只有轉業了。

SPA

不是指水療。是 single page web application 的縮寫。中文翻譯為 單頁應用程式 或 單頁Web應用。更多解釋清參看 百度百科：SPA

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

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

• 1

如上的 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

• 1

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

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

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 插入一條新的資料，我們插入的資料，將是JOSN利用物件傳輸的。

get 操作 /api/v1/love/1

我們獲取到一個 ID 為 1 的的資料，資料一般為一個物件，裡面包含了 1 的各項欄位資訊。

put 操作 /api/v1/love/1

我們向介面提交了一個新的資訊，來修改 ID 為 1 的這條資訊

delete 操作 /api/v1/love/1

我們向介面請求，刪除 ID 為 1 的這一條資料

由上述例子可知，我們實現了5種操作，但只用了兩個介面地址， /api/v1/love 和 /api/v1/love/1 。所以，採用這種介面風格，可以大幅的簡化我們的介面設計。

以上內容均為本人的認知與理解，與標準教科書肯定不一樣。但有助於新人簡潔明瞭的理解內容。更多內容，請檢視：RESTful API 設計指南 
另外，RESTful 風格也不僅僅只有這幾種操作，還有更多的操作。但我們常見的操作，就是這些。就好比我們不需要掌握了男女的全部衛生知識再去做愛一樣，我一般崇尚的是，脫掉褲子，just do it now! 我們在不斷的實踐中，不斷的提高我們的技術以及技巧，臨淵羨魚不如退而結網就是這個道理。

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 系統，並且關於系統底層的問題，我根本就不知道如何解決。

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

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

如果文章由於我學識淺薄，導致您發現有嚴重謬誤的地方，請一定在評論中指出，我會在第一時間修正我的博文，以避免誤人子弟。

本文由 FungLeo 原創，點選-首發連結