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

缺乏、安全感 2022-05-29 20:57 185阅读 0赞

# 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][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 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工作站以及相关文章索引][MAC]
3.  如果不是 `photoshop` 的重度用户，并且想要更深层次的掌握更多内容，请使用 `linux` 系统。`ubuntu` 操作系统还是比较简单上手的。有一定 `linux` 使用经验的同学，建议使用 `arch linux` 操作系统，新手不要尝试，因为你一定安装不上。
4.  除了使用 `atom` 或 `vscode` 这样的现代编辑器，更推荐掌握 `vim` 这样基于`cli`的编辑器的基本使用。能用到什么样的层次，取决于你自己的需求，相关内容可以参考：[世界上最牛的编辑器： Vim][Vim]系列博文。

最后强调，别问我有关 windows 的问题，我很久没用过 windows 系统，并且关于系统底层的问题，我根本就不知道如何解决。

我说的，你不一定要全部掌握或者理解。但一定要有一个起码的概念。至少，知道我说的大概是一个什么样的玩意儿。

第一篇博文，基本没有涉及到任何代码的部分，但是下面，我们要开始干活儿了。

> 如果文章由于我学识浅薄，导致您发现有严重谬误的地方，请一定在评论中指出，我会在第一时间修正我的博文，以避免误人子弟。

[SPA]: https://baike.baidu.com/item/SPA/17536313#viewPageContent
[RESTful API]: http://blog.csdn.net/fungleo/article/details/72271887
[MAC]: http://blog.csdn.net/fungleo/article/details/57572537
[Vim]: http://blog.csdn.net/fungleo/article/details/53128157