Vue.js---------------1引入

Vue.js

vue对比其他

一套用于构建用于界面的渐进式js框架。

构建用户界面：将拿到的数据通过某种办法变成用户可以看见的界面。

至于怎么拿到的data，至于是发送请求、还是固定不变，vue不关心。

原生js是手动挡；jquery是自动挡但是转弯、油门还是需要你动手，jqueyr是类库而非框架；vue是无人驾驶，功能完善大而全说明目的地即可。

vue特点

组件化开发,提高代码复用率，且更易维护。

一个.vue文件就是一个组件，包括html骨架，css样式，js交互，一旦新项目或者别人想用，直接拿过去.vue文件，修改一下内容以及请求地址，数据渲染逻辑就可以复用了。

最大的好处就是更好维护，假如一个页面多个组件，当你修改一个组件里面的css样式，绝对不会影响其他组件的css，即便是重名了。

声明式编码提高开发效率。

虚拟dom+diff算法，尽量复用dom节点：

当数据变化了，可能只是多了一条数据，前面你还有三条和之前一样，原生js是将重复的数据也删除，重新将数据进行渲染。

而vue在数据与dom之间，创建了虚拟dom，会先将数据变为虚拟dom，然后将虚拟dom渲染到页面真实dom上，虚拟dom就是内存里面的数据

当有新的数据时，新的虚拟dom会与旧的虚拟dom进行比较，当发现标签、属性等都一样的时候，会直接复用。

类库与框架的区别：

类库对项目的侵入性小，性能或其他有新的改变，更换一种实现即可。

框架对项目侵入性大，更换版本还好说一点，如果更换框架要重新架构项目，但框架提供完善的解决方案。

早期的前端就是html和css，根本没有js，就和pdf文件没有区别，随便刷新。

但应用越来越五花八门，更像app的感觉，刷新会导致用户体验不好，刷新的本质是摧毁dom，然后重建dom。

谷歌提出SPA的改变，单页面应用，全程无刷新，全程就一个dom不摧毁，在一个dom里面来回切，即MV*模型，而vue属于其中的MVVM。

MV*看待问题的世界观变了，从早期的前端校本化向前端工程化迈进。

背景：

1：js框架，尽管已经有了jQuery，但是jquery还是需要你动手去操作dom。jQuery是命令式，vue是声明式，jQuery渐渐退出历史舞台。

2：ES6之前js没有OOP，尽管可以做成闭包，但是很丑陋，可读性弱。

3：原来的网页和静态页面几乎无异， ajax还好一点，比较平滑，就像图片一样频繁刷新无所谓，但是越发展越无法容忍，因为需求越来越像app。

4：es6之前，js代码很烂，bug很多。

刷新的本质是摧毁原来的dom，进行重新渲染，关键恶心的是原来页面里面的数据没有了，上一个页面的变量不能直接携带到下一个页面。

举个不会这么做，但是道理一样的例子，第一页写username，第二页写密码，写完第一页到了第二页，username不想用了，要退回去，退回去不希望username是空的吧？

此时你就不得不做恶心的事，要么把上一个页面的数据寄存到一个地方，到了下一个页面再把数据取出来放到新的页面里面，这是最恶心的。

尽管你可以放到session中暂存，或者放redis中，要么就放数据库里面，放到远端，传回来又要时间，访问量高了服务器压力立马上来了。

4：因此出现了SPA：single page application概念，单页面应用，页面全程无刷新，在一个dom里面来回切。

概念梳理

虚拟dom：dom----->html 这中间浏览器负责渲染。

后端传来的是html字符串，如果仅仅是一个纯粹的HTML页面还好说。

但现在的网页中会插入各种css、js代码，尤其是js代码会绑定事件或者css定位一个游戏广告。

效率立马降低了。

例如一个js文件里面，有三个步骤。

1-抓取dom树，填入数据100.

2-抓取dom树，绑定点击监听事件。

3-抓取dom树，插入一段HTML代码。

每一步操作dom后，浏览器都会进行一次渲染，上面三步浏览器渲染了三步。

而vue2.0引入的虚拟dom，不一样。

在内存中先创建一个虚拟dom对象，将上述三步操作全部在虚拟dom中操作一遍后，浏览器一次性将虚拟dom对象渲染为html页面

传统是吃一个瓜子皮，去垃圾堆扔一次瓜子皮。

vue是将所有的瓜子皮打包，吃完后一起扔到垃圾箱，明显后者效率更高。

 

其他几个概念：工程化   软件工程    类库    框架 

软件工程的目的是为了复用，不是低级的copy后改一改，而是符合开闭、理氏、依赖倒转等原则的高级复用。

工程化：一个工作如何分配给多人，多人协同配合开发，尽管前端工程化webpack就和maven一样难用。

写代码无法避免的去copy代码，既然无法避免那么如何做的更优雅一点呢？

OOP编程思想的开闭原则，开：对扩展开放。闭：对修改封闭。

别人写的代码用和扩展没关系，但是不能修改，因为你不知道人家写的是什么，一旦改了会发生无法预知的问题。

类库：打开即用，import 类，然后就可以使用。

既然类库引入就能用，说了一个问题，那就是许多东西是可以进行配置的，这就又上升了维度。

更多的模块组织在一起，例如wsgiref、路由、视图、模板、rom等模块，并且完成可配置，逐渐发展起来的叫框架

框架是可以高复用的，例如Django框架，每个人都可以创建django工程，按照自己的业务逻辑配置，二次开发。

看框架源码会发现里面有许多蹩脚复杂的东西，甚至都不明白为什么搞得这么复杂，又是反射又是装饰器，之所以搞得这么复杂，就是为了优雅的复用，让开发者开发更迅捷。

 

Vue是框架，jquery仅仅是个类库，不是一个量级，jquery是个弟弟。

最低级的复用：一段代码拷贝一下，黏贴到了另一个py文件中，稍微改一改功能完成了，项目的体积也变大了，过了几个月，重新维护项目，里面充斥大量冗余的代码，自己都不认识了更别说别人了，难以维护。

js框架发展史

第一代：jquery操作dom，尽管比原生js好的多，代码量少了，但是程序员还是需要调用api去操作dom，最恶心的是js代码里面充斥着填充html的代码，二者耦合在一起。

第二代：MVC，代表就是react，尽管这是前端的模型，

实例：现在有个项目，分别是PC端、手机端、ipad端

这里有两个MVC，一个是后端的MVC、一个是前端的MVC

后端：M：指数据库

　　　C：指接口，例如Django里面的视图函数

　　　V：指的是整个前端。

前端工程化后也分MVC：

　　   M：后端传来的json数据

　　　V：指的是dom，你可以看到的页面。

　　　C：指的是你用js代码或jquery写的，抓取dom树，提取json数据，塞到dom树的逻辑代码，可以视为一些函数。

第一个周：项目经理让开发一个PC端页面

　　  PC端显示LOL玩家的对局场数，KDA，段位，等级，日期，假设这些数据就在一张表内。

　　此时后端开一个接口，从数据库拉出数据，打成json回应前端。

　　前端拿到数据作为M，然后用js写Controller，将json数据处理，爬取dom树，将数据塞进去，

　　然后view显示数据。

第二个周：项目经理让开发手机端

　　手机端显示玩家的KDA、段位、等级即可

　　此时后端又开一个接口，同样从相同的表中拉取数据，打成json回应前端。

　　前端拿到数据后，写新的Controller，因为数据变了，页面也变了，重新抓取dom树，将json中的数据塞进去。

　　view显示数据

第三周：项目经理又来了，让你开发ipad端

　　ipad端让你显示玩家的KDA和段位，此时需要将数据处理用柱状图显示kda

　　后端又开一个接口，还是那张表拉数据，打成json回应前端

　　前端拿到数据后，写心得Controller，然后同上。

这三个小项目，后端开了三个接口，却都是对同一张表中的数据进行了自以为的，按需求的数据截取处理。

为什么不能一次性将所有数据都传过去呢？为了降低IO？为了优化？

最后是，DB不变，写了三个后端接口，传给前端三份不同的数据，前端写了三个controller处理json和dom，渲染了三个不同的view。

　　　　|<------------------------------------------------------------------------------------>|   |<---------------------------------------------------------------------------------------------------------->|

但实际上，　完全可以共用一个后端接口，三个view公用一个data                         前端的controller逻辑完全相同只是处理的数据不同而已，完全可以复用，经过配置达到高级复用，即框架

忽略后端看前端。

此时前端共用后端一个接口传来相同的M，View是不同的，C同样不同。M得到复用。

新项目，页面和刚才的项目完全相同，只是底层的data不同，如何开发？

拷贝过来改改后端的sql接口逻辑，假如v完全相同，此时的c你不能复用，因为c与data相关，新项目传来的data与原来不同，只能将controller拷贝后进行修改

一个单独M+一个单独V，决定一个单独的C

此时发现第一个项目的data可以复用，第二个项目的v可以复用，而c始终无法复用，你成了C，总是站在需求的角度上不停的改动，而这种改动是毫无技术含量的改动。

就是傻瓜式的抓取dom，处理json数据，然后装进dom里面。这种局面亟待解决！

MV*

因为前端的C根本没有涉及复杂的业务逻辑，不像后端变化太多，就是数据变了后view怎么变，绑事件，抓dom树填入数据等，需求完全可以穷举出来。

vue充当中间的双向数据绑定，事件监听，即c的角色，只不过改为vm了而已。

前端view和model任意一方变了，另一方怎么变，需要程序员去指定规则，而这些规则vue都穷举出来，指定好了，即vue的语法。

用了vue就不要再去手动操作dom，别用原生js的getElementById，用了就剁手。

MVVM

M 负责数据存储

V 负责页面展示

VM 负责业务逻辑处理，对data处理后交给V展示，开发者无需手动编写代码指定一方动另一方怎么动，只需要按照vue的规则进行生命即可。

这样前端M可以由后端的接口传来数据，多个项目如果处理的是同一张表，那么完全可以复用。

V这个没办法复用，因为需求中页面会有不同，需要开发者自定义合理布局和数据展示。

C的角色现在由vue来充当，且换了个名字叫vm。

 

伪造

作为后端永远是不相信前端的，前端的一切都可以伪造出来！