Vue,你好
初识Vue今天终于学习了Vue框架,真的特别强大,强大的数据双向绑定已经代码修改后,不需要修改页面,页面就会被更新(重绘),Vue对数据的操作非常的强大,声明式渲染、组件化思想、状态管理都十分的出色、Vue不愧是三大框架中的佼佼者Vue执行流程<!DOCTYPE html><html><head><meta charset="UTF-8"...
初识Vue
今天终于学习了Vue框架,真的特别强大,强大的数据双向绑定已经代码修改后,不需要修改页面,页面就会被更新(重绘),Vue对数据的操作非常的强大,声明式渲染、组件化思想、状态管理都十分的出色、Vue不愧是三大框架中的佼佼者
Vue执行流程
<!DOCTYPE html>
<html>
<head>
<meta charset="UTF-8">
<title>Hello,Vue</title>
</head>
<body>
<div id="app">
{{message}}
</div>
<script src="vue.js" type="text/javascript" charset="utf-8"></script>
<script type="text/javascript">
var app=new Vue({
el:'#app',
data:{
message:'Hello Vue'
}
});
</script>
</body>
</html>
1.浏览器从上到下依次进行解析
浏览器对于id= app的 div 内部的{{message}}是不认识的,直接作为普通的文本输入到浏览器页面上。当浏览器继续往后执行这段代码的时候,发现有一个JS的脚本,发起请求进行下载,当页面环境拿到JS脚本后 Vue.js就会执行,当执行结束的时候,就会全局暴露一个对象:Vue。当解析执行到我们自己写的JS代码的时候,就开始执行我们自己的代码,并且创建Vue的实例(new Vue),通过el属性指定要控制Vue程序的范围,通过data想Vue的实例的应用程序初始化了message成员。然后Vue通过el属性指定id 为 app的 div,开始解析并执行Vue能够识别的语法,{{message}}在Vue中被称为双花括号插值表达式,在双括号插值表达式中可以使用当前元素 所属的vue程序,控制范围中的data 数据。
Vue是渐进式框架
为什么说Vue是渐进式框架呢?Vue从设计的角度来讲, 虽然能够涵盖这张图上所有的东西，但是你并不需要一上手就把所有东西全用上 ，因为没有必要。无论从学习角度，还是实际情况，这都是可选的。声明式渲染和组件系统是Vue的核心库所包含内容，而客户端路由、状态管理、构建工具都有专门解决方案。这些解决方案相互独立，你可以在核心的基础上任意选用其他的部件，不一定要全部整合在一起。
何为声明式渲染
现在基本所有的框架都已经认同这个看法——DOM应尽可能是一个函数式到状态的映射。状态即是唯一的真相，而DOM状态只是数据状态的一个映射。如下图所示，所有的逻辑尽可能在状态的层面去进行，当状态改变的时候，View应该是在框架帮助下自动更新到合理的状态，而不是说当你观测到数据变化之后手动选择一个元素，再命令式地去改动它的属性。
Vue的编译器在编译模板之后，会把这些模板编译成一个渲染函数 。
而函数被调用的时候就会渲染并且返回一个 **虚拟DOM的树 **。
这个树非常轻量，它的职责就是描述当前界面所应处的状态。当我们 有了这个虚拟的树之后，再交给一个patch函数，负责把这些虚拟DOM真正施加到真实的DOM上 。在这个过程中，Vue有自身的响应式系统来侦测在渲染过程中所依赖到的数据来源。在渲染过程中，侦测到的数据来源之后，之后就可以精确感知数据源的变动。到时候就可以根据需要重新进行渲染。当重新进行渲染之后，会生成一个新的树，将新树与旧树进行对比，就可以最终得出应施加到真实DOM上的改动。最后再通过patch函数施加改动。
这样做的主要原因是， 在浏览器当中，JavaScript的运算在现代的引擎中非常快，但DOM本身是非常缓慢的东西 。当你调用原生DOM API的时候，浏览器需要在JavaScript引擎的语境下去接触原生的DOM的实现，这个过程有相当的性能损耗。所以，本质的考量是，要把耗费时间的操作尽量放在纯粹的计算中去做，保证最后计算出来的需要实际接触真实DOM的操作是最少的。
组件系统
现在很多的框架都走上了组件化的道路,组件的思想,每一个页面 都是一个组件,在Vue中，父子组件之间的通信是通过 props 传递。从父向子单向传递；而如果子组件想要在父组件作用里面产生副作用，就需要去派发事件。这样就形成一个基本的父子通信模式，在涉及大规模状态管理的时候会有额外的方案
状态管理
状态管理，本质上就是把整个应用抽象。脸书最早提出 Flux 这个概念的时，也是一个很松散的概念，而且官方的实现本身做得很难用。所以，社区就做了各种各样的探索。图中的这三个东西是一个单向数据流，State 驱动 View 的渲染，而用户对 View 进行操作产生 Action，会使State产生变化，从而导致 View 重新渲染
总结
任何情况下都需要 声明式的渲染功能 ，并希望尽可能避免手动操作，或者说是可变的 命令式操作 ，希望尽可能地让DOM的更新操作是自动的，状态变化的时候它就应该自动更新到正确的状态；我们需要 组件系统 ，将一个大型的界面切分成一个一个更小的可控单元； 客户端路由——这是针对单页应用而言，不做就不需要，如果需要做单页应用，那么就需要有一个URL对应到一个应用的状态，就需要有路由解决方案； 大规模的状态管理 ——当应用简单的时候，可能一个很基础的状态和界面映射可以解决问题，但是当应用变得很大，涉及多人协作的时候，就会涉及多个组件之间的共享、多个组件需要去改动同一份状态，以及如何使得这样大规模应用依然能够高效运行，这就涉及大规模状态管理的问题，当然也涉及到可维护性，还有 构建工具。现在，如果放眼前端的未来，当HTTP2普及后，可能会带来构建工具的一次革命。但就目前而言，尤其是在中国的网络环境下，打包和工程构建依然是非常重要且不可避免的一个环节。
前往低代码交流专区
更多推荐
3
0- 0
已为社区贡献3条内容
所有评论(0)