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

版权声明:本文为 FengCms FungLeo 原创文章,允许转载,但转载必须注明出处并附带首发链接 https://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

如上的 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 插入一条新的数据,我们插入的数据,将是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 正在新旧交替,江山未稳,因此我们当时尝试在两个项目中引用不同的技术路线 reactvue

实践证明,这两个都是非常优秀的框架。但是同时也证明,在前端初学者的面前,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-loadernode-sass css 预处理。
  8. element 基于 vue 的后台组件库。
  9. iview 基于 vue 的另一套后台组件库。
  10. vue-cli vue 项目脚手架。一键安装 vue 全家桶的工具。

其他还有很多,我们用到哪边,说哪边。

命令行的重要性

如果你依然沉浸在 GUI 的图形界面中无法自拔,对于 CLI 命令行充满恐惧或者敌视,那么,现实会残酷的告诉你,你落伍了。

虽然有很多项目在尽力的实现这些内容的可视化操作,例如 iviewiView Cli ,我虽然肯定这些卓越的工程师做出的艰辛的努力,但是,不可否认的说,它也没有彻底的拜托命令行。

并且,命令行

更好

更快

更强

更装逼

所以,无论如何,你都不应该排斥命令行,还要积极的拥抱它,学习它,掌握它。

甚至,关注我博客的同学可能会注意到,我前面自己甚至写了很多的 shell 的相关博客。要知道,我可是一个老前端工程师。这里我不是显摆我的资历,而是客观的评价自己,已经跟不上时代了。我所掌握的那些知识,是非常陈旧的。因此,只有不断的学习,才能不断的提高自己。

我对你的建议如下:

  1. 抛弃 windows 操作系统,不管它是什么版本的 windows
  2. 购买一台 macbook pro 没钱购买可以选择 黑苹果 ,可以参考我的系列博文 打造前端MAC工作站以及相关文章索引
  3. 如果不是 photoshop 的重度用户,并且想要更深层次的掌握更多内容,请使用 linux 系统。ubuntu 操作系统还是比较简单上手的。有一定 linux 使用经验的同学,建议使用 arch linux 操作系统,新手不要尝试,因为你一定安装不上。
  4. 除了使用 atomvscode 这样的现代编辑器,更推荐掌握 vim 这样基于cli的编辑器的基本使用。能用到什么样的层次,取决于你自己的需求,相关内容可以参考:世界上最牛的编辑器: Vim系列博文。

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

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

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

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

本文由 FungLeo 原创,允许转载,但转载必须保留首发链接。

阅读更多
换一批

没有更多推荐了,返回首页