Vue.js设计与实现，读书笔记第一章

第一章：权衡的艺术

1.1命令式和声明式

jq是命令式,关注过程，jq针对简化dom 而产生的

vue是声明式，关注实现，不严格地说就像是在命令式(关注过程)基础上再对标签进行了一次封装（关注实现）

jQuery	命令式	关注过程	简化dom 而产生的
Vue	声明式	关注实现	针对用户产生声明部分

而事实也是，vue内部是命令式，但呈现给用户（程序员）的是声明式的部分

1.2性能与可维护性的权衡

性能对比原则或理论：基于以上比较，理论上声明式在性能上是不能超过命令式的

//不过命令式要代码一一对应实现，初次学习，感觉vue会在复用性上优化性能

而且在声明式的部分，是无法做到内部命令式的部分操作的，vue的把命令的部分交给了自己的源码，用户只需操作得到自己想要的即可，确实提升开发效率

例如：`

而声明式不需要我们关心DOM元素的创建更新删除

//本质都是对dom的操作，声明式原本性能并不比定义式强，只是复用起来，省去了许多声明，从而在整体上优化了性能；官网文档有和react的比较，再写

而之所以性能不如定义式，在于，面向用户的声明式要进行B（代替找出差异消耗的性能）

对于B:一个框架在对元素进行修改（场景就是维护项目），需要

比对需要修改的地方，这里所消耗的性能`用B代替

面向用户的命令式部分就是多了这部分B，

//挺抽象哈，这个例子很形象的帮我理解了两种差别

1.3虚拟DOM的性能到底如何

前置条件：由于很难写出绝对极致的命令式语句；即使写出了，也消耗了相当高的成本，投入产出并不高；因此产生了虚拟DOM,执行B,寻求产出比的下限

以上内容其实是针对JavaScript中的DOM来讲的，我们首先要清楚框架的核心其实就是简化DOM操作目前来讲，当然他配套的生态也十分的重要

在学习《JavaScript DOM编程艺术》一书中提到相同的问题；就是innerHTML的特殊性，下面展开来讲：

innerHTML创建网页需要构造一段HTML字符串

const html ='<div><span>...</span></div>'

接着讲此字符串赋值给DOM元素的innerHTML属性

div.innerHTML =html

远没有上面两句话那么简单：为了渲染页面，首先字符串要解析成DOM树，涉及到DOM层的运算必然不如JavaScript层面

用1万次测试

因为是万次级别的测试，但我们仍看出了性能差别上命令部分比原生js几乎差了1倍

自此inner HTML创建网页的性能公式：A+B,
A:HTML字符串拼接的计算量+inner HTML的DOM计算量

那么虚拟DOM是如何渲染我们的页面的？

//准确来说是创建

两步：

1.创建JavaScript对象（这里的对象可以理解为真实的DOM）

2.递归遍历虚拟DOM树并创建真实DOM(虚拟dom的虚拟原来是指遍历虚拟dom树)

虚拟DOM的性能公式：A十B;A:创建.TavaScripti的计算量B:创建真实DOM的计算量

可以看出innerHTML更新页面的过程就是重新构建HTML字符串，再重新设置DOM;

这需要我们即使只修改了一个文字，也要全部执行者3部操作；而且是销毁

全部旧DOM元素，全量创建新的DOM元素

//这点上我觉得和jq中学习深浅拷贝有关系；简单来说就是命令式会覆盖（比如jq对象的浅拷贝覆盖，深拷贝保留）

看看我们虚拟dom是怎么更新页面数据的：

B的对比不同在这方面起到了不同

也就是：虚拟dom只更新需要更新的局部内容，这就是虚拟dom的优势，你可能会说上面的diff性能消耗，这一算法在后面会分析，这里提一句diff算法在JavaScript层面运算，不会产生数量级的差异（差异有但不明显，忽略）；反正能原生层面解决的东西性能肯定不会差

于是各自性能与什么条件有关就显现在下面了：

正在上传…重新上传取消

innerHTML在页面越大时，更新性能消耗越大；虚拟dom和更新量有关

//这里vue的虚拟dom是不是用的diff算法来监测不同的，留个疑问

粗略比较下原生，虚拟dom和innerhtml这三者在更新页面时的性能：

正在上传…重新上传取消

这里原生JavaScript指的是它的dom操作

所谓心智指的是：传统的增删改查，也就是：手动创建，删除，修改大量dom原素

innerHTML在字符串拼接方面表现的有些接近声明了

//命令式和声明式只是个帮助我们理解的名词，不要认为vue有，其他的框架就不能有类似的地方

1.4运行时和编译时

那么综合上面各项指标的取舍，有没有鱼和熊掌兼得的东西

//折中

设计框架时有三种选择：纯运行时的，运行时+编译时的或纯编译时的

聊聊纯运行时：

假设设计了个框架，提供了一个Render函数，用户只需要提供一个树形结构的数据对象；之后这个函数会递归地将数据渲染成DOM元素

规定树形结构的数据对象如下：

 const obj = {
      tagL: 'div',
      children: [
        {
          tag: 'span',
          children: 'hello world',
        },
      ],
    };

在这个对象中有两个属性：其中tag代表标签名，children既可以是一个数组（代表子节点？？？是说数组里数组这种类嵌套吗？）也可以是一段文本（代表文本子节点）

Render函数设计实现：

 function Render(obj,root){
      const el =document.createElement(obj.tag)
      if (typeof obj.children === 'string'){
        const text=document.createTextNode(obj.children)
        el.appendChild(text)
      }else if(obj.children){
        //数组，递归调用Render,使用el作为root参数
        obj.children.array.forEach((child)=>Render(child,el))
      }
      //元素添加到 root
      root.appendChild(el)
    }

用户实现提交，无需额外学习知识，不需要额外步骤，为Render提供一个树形结构的数据对象即可；

// 用户实现
    const obj = {
      tag: 'div',
      children: [
        {
          tag: 'span',
          children: 'hello world',
        },
      ],
    };
    //渲染到body下
    // Render(onj, document.body)

直到有一天用户抱怨：不愿意手写数据结构对象，而且不直观，能不能用类似HTML标签的方式描绘数据结构对象呢，你看了看Render函数，摇了摇头，暂不支持，以上就是一个纯运行时的框架

为了满足用户需求，你开始思考能不能引入编译的手段，把HTML编译成树形结构的数据对象，这样我们就可以继续使用Render函数了

为此我们要写一个名为Complier的程序，作用就是实现上面把HTML字符串（标签里的东西）编译成树形结构的数据对象

用户怎么用呢，最简单的就是让用户分别调用Compiler函数和Render函数：

//设计运行时+编译时框架
    const html = `<div>
        <span> hello world</span>
      </div>`
      // 看起来``和（）在这里作用似乎是一样的
      //调用Complier 编译器得到属性结构的数据对象
      const obj= Compiler(html)
      //再调用Render进行渲染
      Render(obj,document.body)

以上构成了运行时加编译时的框架；准确讲是运行时编译

具体来讲它支持运行时，用户可以直接提供数据对象而无需编译；又支持编译时，用户可以提供（？）字符串，我们将其编译为数据对象后交付运行处理

也就是代码运行时才开始编译，而这会产生一定性能的开销，因此我们也可以在构建阶段就执行compiler将用户提供的内容编译好，等运行就不用编译了，这对性能是友好的

这引起我们的思考，既然编译器可以把HTML字符串编译成数据对象，那为何不直接编译成命令式代码呢？

于是