Vue2+VueRouter2+Webpack+Axios 构建项目实战2017重制版（一）基础知识概述

首先说明一下，本人作为一名java后端小白，想自己做一些项目，所以就自学了Vue，然后上网看到了这篇写得很不错的博客，于是转载下来，方便更多人学习，也方便自己学习！！！！这篇博客讲解得很详细，内容也广泛，很适合初学vue的同志们看！！！

转自：http://blog.csdn.net/FungLeo/article/details/77575077

Vue2+VueRouter2+Webpack+Axios 构建项目实战2017重制版（一）基础知识概述

前言

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 原创，允许转载，但转载必须保留首发链接。