作者：郑韩京
出版社：人民邮电出版社
格式: AZW3, DOCX, EPUB, MOBI, PDF, TXT
Vue.js前端开发基础与项目实战试读：
前言
Foreword刚开始接触Vue.js框架时，我就被其轻量、组件化和友好的应用程序接口（Application Programming Interface,API）所吸引。之后经过深入研究与实际开发，更加意识到Vue.js的奇妙。再后来研究了其他MVVM框架，几经对比后，发现Vue.js依然是最适合初学者学习的MVVM框架之一，其学习成本低、效果好，是前端开发的不二之选。
我将多年的知识积累与实际开发经验浓缩成这本书，从简到难，并且通过实际开发的案例来分析，深入浅出、图文并茂，力求将枯燥的知识用诙谐幽默、浅显直白的方式叙述出来。本书抛开了冗余难懂的理论化内容，除实战需要用到的必备知识外，没有其他多余的内容，绝不贪多求全，尤其强调实际操作、快速上手，并且侧重点绝不是展示示例（Demo），而是更注重实战开发——从如何分析涉及项目、如何构建项目框架到项目实际开发、数据库配置、后端接口的配置，读者学到的都是项目开发中所需要的知识，项目构建的整体过程。
本书主要分为基础准备篇与项目实战篇，其中基础准备篇涵盖了项目开发需要的各种内容与工具，并做了详细的讲解。
1.前端历史的介绍“以史为镜，可以知兴替”。从前端最开始的故事讲起，介绍这20多年来前端的发展。讲解前端如何从静态网页到如今的单页面应用，其间不断的革新是由无数人一步一个脚印走出来的，发展的艰辛可想而知。了解前端的历史的目的，主要就是明确前端的发展方向，以便有的放矢地学习。
2. Vue.js基础知识的介绍
这部分主要介绍了后期实战所需用到的Vue.js相关知识，从两个简单的Demo先了解Vue.js的特性，之后根据这些特性来逐步分析学习Vue.js的知识。此外，还单独列出一章，讲解Vue.js组件的相关知识，不仅仅是因为组件知识比较重要，还因为组件知识的内容也比较复杂，尤其是组件之间信息的传递，相对来说比较复杂。
3. ES6语法介绍
后期实战代码中较多使用了ES6语法，而ES6与前代ES5语法区别较大，若不加以讲解，可能有些读者无法理解，有可能严重影响开发进度。书中详细讲解ES6的重点特性，并辅以例子方便读者理解。
4.前后端项目框架构建
为项目实战做好基础工作，在脚手架工具的基础上二次开发，得到了具备一定程度上自动化解析代码的方法，为项目的开发提供了很好的底层内容。
第2篇为项目实战篇，以网页版知乎为例，介绍如何实现主要的增、删、改、查功能，帮助读者了解项目实际开发中需要经历的流程，并且熟练使用Vue.js来构建项目。
1.基础部分的开发
本部分介绍页面整体框架与用户登录、登出功能的实现方法，如何使用Cookies存储用户登录信息以及页面相应的展示状态，并对项目的逻辑层也进行简单介绍。
2.文章问题回答等一系列内容的增、删、改、查
实战项目的主要内容，从增、删、改、查的角度为读者介绍前后端的操作逻辑，让读者对项目的整体流程有一个更立体的认识，能熟练使用Vue.js对数据进行各种形式的展示及灵活调用组件。本部分对代码的解耦和复用性也做了一定程度上的介绍，帮助读者养成更好的开发习惯，促进职业道路的发展。
3.个人信息的展示与修改
对整个项目的展示与修改，通过规范化配置与组件的灵活调用，力求用最少的代码实现此功能，同时对整个项目的内容进行梳理，对每种类型的内容的存在与意义有了更深刻的认识。
4.前后端项目的部署
从购买服务器、配置服务器到项目的实际部署，一步步教会读者独立部署项目，并且介绍相关工具的使用，扩展读者的知识面，让读者对开发有更长远的认识。
本书读者对象
本书包括基础内容和实战项目，适用于刚接触Vue.js的前端或后端开发者。当然，有一定Vue.js开发经验的读者也能从中收获不少实战经验。第1篇 基础准备篇第1章 关于前端开发你需要知道的事
在开始讲解技术之前，首先需要了解一下关于前端开发的一些事——前端开发的历史、前端的发展过程、前端的现状等。这些知识并非毫无用处，因为只有对前端有了更好的理解，我们对整个开发过程的认识才能更加深刻，对前端的功能改善与整体项目的布局才会有更好的想法。
本章主要涉及的知识点如下。
前端开发的历史
前端的三大框架
前端开发工具的日常使用1.1 网页开发的前世今生
我们知道，历史有其独特性，是无法抹去的。只有牢记历史，才能更好地面对未来。前端出现的时间不长，迄今为止只有20多年。但这20多年间，前端的变化可以说是翻天覆地的。1.1.1 是否还记得曾经的前端开发
1994年秋天，网景推出了第一版Navigator，也是这个秋天，万维网（World Wide Web, W3C）在麻省理工学院计算机科学实验室成立。同年，CSS的概念被提了出来（之前只有RRP）。几个月后，一个加拿大人为了追踪访问他个人主页的用户的数据，开发出PHP的前身。以上种种事件的发生，宣告着前端正式出现在人们的视野中。
万维网创建的初衷是为了方便欧洲核子研究组织的科学家们查看文档、上传论文。这也就解释了为什么Web网页都是基于Document的。Document就是用“标记语言+超链接”写成的由文字和图片构成的HTML页面，这样的功能已经完全可以满足学术交流的需要，所以网页的早期形态和Document一样，完全基于HTML页面，并且所有内容都是静态的。这也解释了为什么原生JavaScript（简称“JS”）用document.getElementBy获取页面元素。
最开始的网页在很多方面都受到限制，当时JS还没有出现，没有任何手段可以对页面进行修改，就连最简单的显示或隐藏都做不到，所以，不管网页之间的变化有多小，只要有变化，就要重新加载一个页面。同时本地无法对数据进行任何操作，所有计算都是在服务端完成的。虽说这些在现在看来，可能只是些很好解决的小问题，但是当时的网络运行不流畅，网速与现在相比完全没有可比性。所以，在当时用户提交一个表单后，屏幕首先会出现一片雪白，经过漫长的等待，可能返回一个一模一样的页面，只是在输入框下面出现了一行红字——用户名或密码输入错误！
除此之外，纯静态页面还带来了另外一个问题：例如一个电商平台有1000种商品，就算布局一模一样，但因为商品不同，还是要写1000个页面，即使是修改其中某个商品，困难都不敢想象。
退一步说，就算网速提高了，但是服务器也受不了这种任何数据计算都要请求的情况，不仅是数据的存储，其数据的处理和返回也对服务器有着极大的要求。所以，前端的数据处理和修改文档对象模型（Document Object Model,DOM）元素的能力真的很重要。
因此，JS于1995年应运而生，它不仅实现了客户端的计算任务，而且减轻服务器压力的用时，降低了网速慢带来的限制。1996年，微软又推出了iframe标签，实现了局部的异步加载。1999年，XMLHttpRequest技术出现，谷歌使用其开发了Gmail和谷歌地图之后， XMLHttpRequest获得了巨大的关注。2006年，XMLHttpRequest被W3C正式纳入标准，同时有了新的名字——Ajax。
Ajax的出现不仅解决了早期前端的众多问题，同时将我们从Web网页时代带到了Web应用时代，也就是常说的Web 2.0时代，同时提出了前后端分离的概念。
Web网页时代与Web应用时代的区别是十分巨大的：在Web网页时代，网页都是服务端渲染的，服务器先渲染出HTML页面，之后糅合JS和CSS文件，再发送给浏览器，浏览器解析这个类似文档的内容，展示给用户。如此便把所有压力都放在服务器，客户端只负责解析服务器返回的文档。但是在Web应用时代，客户端可以自己对数据进行处理，并且做出相应的渲染。不仅分摊了服务器的压力，同时由于数据量的减少，页面的反馈速度也提升了，缺点就是对机能提出了一定的要求，但随着计算机性能的不断提高，这点要求变得微不足道。1.1.2 大前端时代的来临
在Web 2.0时代，网页在某种程度上被当作一个App，浏览器就是运行这个App的容器，在这个App里，前端会对数据进行很多操作，只要不对数据进行永久化修改，就无须请求服务，这使网页独立成为一个整体。
jQuery的出现促进了Web 2.0时代的进步，其优雅的语法、符合直觉的事件驱动型的编程思维使其极易上手，因此很快风靡全球，大量基于jQuery的插件构成了一个庞大的生态系统，更加稳固了jQuery作为JS“库一哥”的地位。
同样，谷歌的V8引擎也搭了把手，因为即使有了jQuery，若是浏览器的解析不到位，依然会制约JS的使用。但V8的出现彻底解决了这个问题，也终止了当时微端对浏览器的垄断。有了V8引擎，浏览器可以更好地对JS进行解析，前端机能一下变得过剩。同时ES5也发布出来，前端整体的发展环境得到了很大的提高，迈入了一个崭新的时代。
在所有准备工作都做好的时候，各大框架出现了，从2009年的AngularJS，到2010年的backbone.js，再到2014年的React、Ember、Vue.js等，这些框架增进了前后端分离的进程。
前后端分离使得前端工程师可以更加专注地开发前端功能，同时避免了前后端共同开发的一些分歧。在前后端分离的架构中，后端只负责按照约定的数据格式为前端提供可调用的API服务即可。前后端之间通过HTTP请求进行交互，前端获取数据后进行组装和渲染，最终展示在浏览器上。
前后端分离的代码库也进行了一定的操作，代码组织方式如图1.1所示。图1.1 前后端分离的代码组织方式
在前后端没有分离的时代，前端工程师进行开发的时候，必须把整个项目都导入开发工具中，页面中可能夹杂了些许后端代码，使项目的修改变得十分复杂，一不小心就可能造成不可预料的后果。
有些前端工程师不满足于仅仅涉猎前端，但后端语言学习的成本又很高，那怎么办呢？Node.js是一个不错的选择。2009年，Node.js出现了，它是一个基于V8引擎的服务端JS运行环境，类似于一个虚拟机，也就是说，JS在服务端语言中占据了一席之地。至此，仅凭JS一门语言就可以开发整个系统了。
其实Web 2.0的眼光更加长远，其更多的是放在替代传统软件上。Web应用相比传统的应用有着太多的好处——无须针对系统来开发不用的版本，无须安装，无须审核，无须升级等。其中最大的好处就是降低了软件的开发成本。虽然理想很好，但是当前制约Web应用的因素也有很多。例如浏览器的处理速度跟不上，对系统功能的调用不完善等。但是目前这些弊端正在渐渐消失，系统权限正在逐步开发出来，Luminosity API、Orientation API、Camera API等日渐完善。谷歌为了促进Web应用的发展，推出了Chromebook，在此款笔记本中，谷歌浏览器（Chrome）被整合到系统中，并且系统中只有谷歌浏览器这一个应用，用户的所有操作都是在谷歌浏览器中完成的，这足以证明Web应用是完全可行的。
除了Chromebook，还有很多程序可以证明Web应用正在逐渐替代传统的应用，最有名的应当是微信小程序，开发者只需要在自己的App中嵌入Weex的SDK，就可以通过撰写HTML/CSS/JS来开发Native级别的Weex界面。Weex界面的生成码就是一段很小的JS，可以像发布网页一样轻松地部署在服务端，然后在App中请求执行。目前，Web应用时代正在如火如荼的发展，相信不久的将来，真的会如阮一峰所说：“未来只有两种工程师——端工程师（PC端、手机端、TV端、VR端……）和云工程师”。1.2 MVC、MVP、MVVM傻傻分不清楚
在开始讲解本节内容之前，先举一个例子，如图1.2所示。
这是一个很简单的计数器，单击“减”按钮，数字就会减1；单击“加”按钮，数字就会加1。图1.2 MV系列框架例子
接下来需要知道的是，在MV系列框架中，M和V指Model层和View层，但是其功能会因为框架的不同而变化。Model层很好理解，就是存储数据；View层则是展示数据，读者能看见这个例子，完全就是因为存在View层。虽然在不同的框架中， View层和Model层的内容可能会有所差别，但是其基础功能不变，变的只是数据的传输方式。
下面就从这个例子开始了解MV系列框架的概念。1.2.1 MVC小解
MVC框架是MVC、MVP、MVVM这3个框架中历史最悠久的。20世纪70年代，施乐公司发明了Smalltalk语言，用来编写图形界面的应用程序，脱离了DOS系统，让系统可视化，不用一直看着黑白的界面。
在Smalltalk发展到80版本的时候，MVC框架被一位工程师提出来，MVC框架的出现在很大程度上降低了应用程序的管理难度，之后被广泛应用于构架桌面和服务器应用程序。MVC框架如图1.3所示（实线表示调用，虚线表示通知）。
Controller是MVC中的C，指控制层，在Controller层会接收用户所有的操作，并根据写好的代码进行相应的操作——触发Model层，或者触发View层，抑或是两者都触发。需要注意：Controller层触发View层时，并不会更新View层中的数据，View层中的数据是通过监听Model层数据变化而自动更新的，与Controller层无关。MVC框架流程如图1.4所示。图1.3 MVC框架图图1.4 MVC框架流程图
从图1.4中可以看出，MVC框架的大部分逻辑都集中在Controller层，代码量也都集中在Controller层，这带给Controller层很大的压力，而已经有独立处理事件能力的View层却没有用到。还有一个问题，就是Controller层和View层之间是一一对应的，断绝了View层复用的可能，因而产生了很多冗余代码。为了解决这个问题，MVP框架被提出来。1.2.2 MVP小解
首先需要知道，MVP不是指Most Valuable Player，而是指Model-View-Presenter。
MVP框架比MVC框架大概晚出现20年，1990年，MVP由IBM的子公司Taligent公司提出，它最开始好像是一个用于C++ CommonPoint的框架，这种说法正确与否这里不做考证，先来看一下MVP框架图（图1.5）。
在MVC框架中，View层可以通过访问Model层来更新，但在MVP框架中，View层不能再直接访问Model层，必须通过Presenter层提供的接口，然后Presenter层再去访问Model层。这看起来有点多此一举，但用处着实不小。首先是因为Model层和View层都必须通过Presenter层来传递信息，所以完全分离了View层和Model层，也就是说，View层与Model层一点关系也没有，双方是不知道彼此存在的，在它们眼里，只有Presenter层。其次，因为View层与Model层没有关系，所以View层可以抽离出来做成组件，在复用性上比MVC模型好很多。MVP框架流程如图1.6所示。图1.5 MVP框架图图1.6 MVP框架流程图
从图1.6中可以看出，View层与Model层确实互不干涉，View层也自由了很多。但还是有问题，因为View层和Model层都需经过Presenter层，致使Presenter层比较复杂，维护起来会有一定的问题。而且因为没有绑定数据，所有数据都需要Presenter层进行“手动同步”，代码量比较大，虽然比MVC模型好很多，但也是有比较多的冗余部分。为了让View层和Model的数据始终保持一致，避免同步，MVVM框架出现了。1.2.3 MVVM小解
MVVM最早是由微软在使用Windows Presentation Foundation和SilverLight时定义的，2005年微软正式宣布MVVM的存在。VM是ViewModel层，ViewModel层 把Model层 和View层的数据同步自动化了，解决了MVP框架中数据同步比较麻烦的问题，不仅减轻了ViewModel层的压力，同时使得数据处理更加方便——只需告诉View层展示的数据是Model层中的哪一部分即可，MVVM框架如图1.7所示。
读者可能感觉MVVM的框架图与MVP的框架图相似，确实如此，两者都是从View层开始触发用户的操作，之后经过第三层，最后到达Model层。但是关键问题是这第三层的内容， ViewModel层双向绑定了View层和Model层，因此，随着View层的数据变化，系统会自动修改Model层的数据，反之同理。而Presenter层是采用手动写方法来调用或者修改View层和Model层，两者孰优孰劣不言而喻。MVVM框架流程图如图1.8所示。图1.7 MVVM框架图图1.8 MVVM框架流程图
从图1.9可以看出，View层和Model层之间数据的传递也经过了ViewModel层， ViewModel层并没有对其进行“手动绑定”，不仅使速度有了一定的提高，代码量也减少很多，相比于MVC和MVP,MVVM有了长足的进步。
至于双向数据绑定，可以这样理解：双向数据绑定是一个模板引擎，它会根据数据的变化实时渲染。这种说法可能不是很恰当，但是很好理解，如图1.9所示。
如图1.9所示，View层和Model层之间的修改都会同步到对方。MVVM模型中数据绑定方法一般有以下3种。图1.9 数据绑定概念
数据劫持
发布-订阅模式
脏值检查
Vue..js使用的是数据劫持和发布-订阅模式两种方法。首先来了解3个概念。
Observer：数据监听器
Compiler：指定解析器
Watcher：订阅者
Observer用于监听数据变化，如果数据发生改变，不论是在View层还是Model层， Oberver都会知道，然后告诉Watcher。Compiler的作用是对数据进行解析，之后绑定指定的事件，在这里主要用于更新视图。
Vue.js数据绑定的流程：首先将需要绑定的数据用数据劫持方法找出来，之后用Observer监听这堆数据，如果数据发生变化，Observer就会告诉Watcher，然后Watcher会决定让哪个Compiler去做出相应的操作，这样就完成了数据的双向绑定。1.2.4 三者的区别和优劣
详细了解MV系列框架之后，相信读者已经了解MVC、MVP、MVVM这三者的优劣了。其实从MVC到MVP再到MVVM，是一个不断进步的过程，后两者都是在MVC的基础上做的变化，使MVC更进一步，使用起来也更加方便。MVC、MVP、MVVM三者的主要区别就在于除View层和Model层之外的第三层，这一层的不同使得MV系列框架区分开来。
其实很难说出MVC、MVP、MVVM哪一个更好，从表面上看，显然是MVVM最好，使用起来更方便，代码相对也较少。但问题是MVVM的框架体积较大，相比于MVC的不用框架、MVP的4KB框架，MVVM遥遥领先。虽然MVVM框架可以单独引用，但现在更多使用前端脚手架工具进行开发，并且使用打包工具，这样一来，它跟MVC相比，体积是天差地别。虽然机能过剩更令人放心，但是轻巧一些的
试读结束[说明：试读内容隐藏了图片]