前言
2016年,我写了一系列的 VUE
入门教程,当时写这一系列博文的时候,我也只是一个菜鸟,甚至在写的过程中关闭了代码审查,否则通不过校验。
本来写这一系列的博文只是为了给自己看的,但没想到的是,这系列博文的点击量超过了2万以上,搜索引擎的排名也是非常理想,这让我诚惶诚恐,生怕我写的博文有所纰漏,误人子弟。
再者,这一年的发展,VUE
项目快速迭代,看着我一年前写的博文,很可能各种提示已经发生改变,对照着过时的资料,非常可能导致新手在学习的过程中产生不必要的困扰。
因此,本人决定,重写这个系列的博文,力求以简明、清晰、准确的图文以及代码描述,配合 github
的项目开源代码,给各位 VUE
新手提供一个高质量的入门文案。
基本理念
通过对接
cnode.js
的公开api
的列表,以及详情页面,实现一个超小型的项目实战,尽可能的掌握vue
的项目入门的各项关键配置。
本系列博文不涉及vuex
的内容。因为这部分内容属于比较高阶的内容,并且在大多数中小型项目中是没有多大用处的。所以情况是,大多数情况下,你并不需要vuex
。当你需要的时候,你应该有看懂官方文档的水平。如果你没有看懂官方文档的水平,我说再多都是没有什么用的。并且在vue
的入门文档中涉及这部分内容的话,会给新手徒增烦恼,所以本系列博文不涉及vuex
的内容。
基础概念论述
前后端分离开发模式
在若干年前,我们的 WEB
项目开发模式是如下的:
- 设计师设计页面设计稿
- 前端工程师切成
html+css+js
的页面 - 后端工程师拿到前端工程师的做好的页面,利用模板引擎或其他技术嵌套进后端代码中,实现项目开发。
这种开发模式的缺点是,哪怕页面出现一点点小的改变,也需要前端人员和后端人员同时协调开发,并且后端人员不能把全部精力放在业务流程以及数据逻辑等方面,还必须和前端人员一起来处理各种兼容问题。开发效率不高,沟通繁琐。
所以,我们推崇前后端分离的开发模式。
- 设计师设计页面设计稿
- 前端工程师和后端工程师以及其他技术人员约定项目开发接口规范
- 后端工程师按照约定接口规范开发相应接口
- 前端工程师开发页面,并对接后端接口(可能先期采用假接口)开发页面
与不分离的开发模式相比,对前端技术人员的技术要求高了很多,原先只需要会写静态页面即可,但是现在必须了解如何对接接口,以及其他很多内容。很多十年以上的前端开发人员在学习这些新内容的过程中,崩溃了。
我经常在我的博客评论里,看到这样的评论 我艹,现在前端开发都这个样子了
。
时代发展浩浩荡荡,你我不进则退,我作为十三年前端开发经验的人,也从13年开始,疯狂学习 JS
相关内容,否则,真的只有转业了。
SPA
不是指水疗。是 single page web application
的缩写。中文翻译为 单页应用程序 或 单页Web应用。更多解释清参看 百度百科:SPA
所有的前端人员都应该明白我们的页面的 url
构成:
- 1
如上的 url
由以下部分组成:
http://
规定了页面采用的协议。www.fengcms.com
为页面所属的域名。index.html
为读取的文件名称。?name=fungleo&old=32
给页面通过GET
方式传送的参数#mylove/is/world/peace
为页面的锚点区域
前面四个发生改变的时候,会触发浏览器的跳转亦或是刷新行为,而更改 url
中的锚点,并不会出现这种行为,因此,几乎所有的 spa
应用都是利用锚点的这个特性来实现路由的转换。以我们的 vue
项目为例,它的本地 url
结构一般为以下格式:
- 1
可以明显的看到我们所谓的路由地址是在 #
号后面的,也就是利用了锚点的特性。
以上理解是我的个人描述,不代表百分百符合标准答案,但这样理解是没有问题的。
RESTful 风格接口
实际情况是,我们在前后端在约定接口的时候,可以约定各种风格的接口,但是,RESTful
接口是目前来说比较流行的,并且在运用中比较方便和常见的接口。
虽然它有一些缺陷,目前 github
也在主推 GraphQL
这种新的接口风格,但目前国内来说还是 RESTful
接口风格比较普遍。
并且,在掌握了 RESTful
接口风格之后,会深入的理解这种接口的优缺点,到时候,你自然会去想解决方案,并且在项目中实行新的更好的理念,所以,我这系列的博文,依然采用 http://cnodejs.org/
网站提供的 RESTful
接口来实战。
了解程序开发的都应该知道,我们所做的大多数操作都是对数据库的四格操作 “增删改查” 对应到我们的接口操作分别是:
post
插入新数据delete
删除数据put
修改数据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
这个系统核心,而是包含了一整套外围工具的完整系统。
具体如下:
vue.js
核心,不解释。VueRouter2
实现路由组织工具。webpack
项目打包以及编译工具。nodejs
前端开发环境。npm
前端包管理器。axios
ajax 接口请求工具。sass-loader
和node-sass
css 预处理。element
基于 vue 的后台组件库。iview
基于 vue 的另一套后台组件库。vue-cli
vue 项目脚手架。一键安装 vue 全家桶的工具。
其他还有很多,我们用到哪边,说哪边。
命令行的重要性
如果你依然沉浸在 GUI
的图形界面中无法自拔,对于 CLI
命令行充满恐惧或者敌视,那么,现实会残酷的告诉你,你落伍了。
虽然有很多项目在尽力的实现这些内容的可视化操作,例如 iview
的 iView Cli
,我虽然肯定这些卓越的工程师做出的艰辛的努力,但是,不可否认的说,它也没有彻底的拜托命令行。
并且,命令行
更好
更快
更强
更装逼
所以,无论如何,你都不应该排斥命令行,还要积极的拥抱它,学习它,掌握它。
甚至,关注我博客的同学可能会注意到,我前面自己甚至写了很多的 shell
的相关博客。要知道,我可是一个老前端工程师。这里我不是显摆我的资历,而是客观的评价自己,已经跟不上时代了。我所掌握的那些知识,是非常陈旧的。因此,只有不断的学习,才能不断的提高自己。
我对你的建议如下:
- 抛弃
windows
操作系统,不管它是什么版本的windows
。 - 购买一台
macbook pro
没钱购买可以选择 黑苹果 ,可以参考我的系列博文 打造前端MAC工作站以及相关文章索引 - 如果不是
photoshop
的重度用户,并且想要更深层次的掌握更多内容,请使用linux
系统。ubuntu
操作系统还是比较简单上手的。有一定linux
使用经验的同学,建议使用arch linux
操作系统,新手不要尝试,因为你一定安装不上。 - 除了使用
atom
或vscode
这样的现代编辑器,更推荐掌握vim
这样基于cli
的编辑器的基本使用。能用到什么样的层次,取决于你自己的需求,相关内容可以参考:世界上最牛的编辑器: Vim系列博文。
最后强调,别问我有关 windows 的问题,我很久没用过 windows 系统,并且关于系统底层的问题,我根本就不知道如何解决。
我说的,你不一定要全部掌握或者理解。但一定要有一个起码的概念。至少,知道我说的大概是一个什么样的玩意儿。
第一篇博文,基本没有涉及到任何代码的部分,但是下面,我们要开始干活儿了。
如果文章由于我学识浅薄,导致您发现有严重谬误的地方,请一定在评论中指出,我会在第一时间修正我的博文,以避免误人子弟。
本文由 FungLeo 原创,点击-首发链接