构造函数

我们使用vue时，会使用

var app = new Vue({
  el: '#app',
  data: {
    message: 'Hello Vue!'
  }
})
 

这里生成了一个Vue实例，显然new关键字后面的Vue是一个ES6的class或者是构造函数。查看源码看到是一个构造函数。

// new Vue会生产出一个对象，这个对象是真正在内存中工作的Vue实例对象。
function Vue (options) {
    // 在用户new Vue时，执行的_init就是下面initMixin添加的方法
    this._init(options) 
}

// 使用构造函数而不使用class语法的好处是：
// 通过 xxxMixin 的函数调用，将Vue的功能拆分到多个模块去实现。
// 它们的功能都是给 Vue 的 prototype 上扩展一些方法。
// 这种方式是用 Class 难以实现的。
initMixin(Vue)
stateMixin(Vue)
eventsMixin(Vue)
lifecycleMixin(Vue)
renderMixin(Vue)

export default Vue
 

在Vue源码中，是使用了ES6语法的，但这里面没有用class来声明，是因为如果写成class声明的类，类会很大，而Vue包含内容多，需要做拆分，所以还是使用构造函数语法，采用了在不同的模块中给Vue构造函数添加功能的方式。

选项对象、Vue构造器、Vue实例对象

在Vue官方文档中，可以看到这样一句话。

在日常开发，写一个组件时，如下：

<template>
...
</template>

<script>
// 这里跟React定义组件不同，不是写继承Component的类，而是写一个简单对象，这只是个选项对象
export default {
    ...
}
</script>
 

首先要清晰的是，我们日常开发中编写的，只是选项对象。这点是区别于React的直接定义React类（或者说是React组件的构造函数）。

我们注意根组件传入的选项对象，data属性是一个对象。而除了根组件，我们编写的选项对象，data属性是一个方法。之所以有这样的区别，是因为根组件是new Vue直接创建Vue实例对象，其他我们编写的选项对象，在代码运行时，先被Vue.extend扩展成继承自Vue构造器的子Vue构造器，再用子Vue构造器实例化出组件实例（即真正工作的vue组件对象）。所以我们编写的选项对象的data属性是被所有组件实例公用的，所以data属性需要是一个方法，为不同的组件实例返回专属的data数据。

总之，区分和清晰选项对象、Vue构造器、Vue实例对象的概念，有助于我们更好的理解Vue运行原理。从上面的分析可以看出作者拥有着很好的面向对象编程思想。

闭包

Vue源码中也些闭包的应用。

缓存变量

// 在讲普通属性变成响应式属性时，dep变量存在于Object.defineProperty方法下的get/set函数的作用域链上，使get/set方法能共享dep对象
export function defineReactive (
    const dep = new Dep()
    Object.defineProperty(obj, key, {
        get: function reactiveGetter () {
            ...
            // 依赖收集
            dep.depend()
        }
        set: function reactiveSetter (newVal) {
            ...
            // 派发更新
            dep.notify()
        }
    }
}
 

因为有闭包，defineReactive方法执行结束后，dep对象并不会被垃圾回收，而是存在于get/set方法的作用域链上。

函数柯里化

用于把 VNode 最终转换成 DOM的patch方法，由于patch方法是平台相关的，在 Web 和 Weex 环境中的DOM和相关操作不同。所以将平台不同的地方抽象出来作为参数，传入一个叫createPatchFunction方法用来生成针对不同平台的patch方法。

// nodeOps, modules是跟平台相关的逻辑，传递给createPatchFunction方法，返回值是patch方法，patch方法内部可以使用nodeOps, modules来进行一些真实dom的操作。
export const patch: Function = createPatchFunction({ nodeOps, modules })
 

柯里化便是闭包的一个应用，这里利用柯里化，实现了patch方法的多态。

这样在VNode 转换成真正的 DOM 节点的过程中，会调用patch方法，其中的只需考虑diff新旧VNode树的逻辑，不需考虑具体操作真实dom的逻辑。

生命周期钩子函数的this指向

new Vue({
  data: {
    a: 1
  },
  created: function () {
    // `this` 指向 vm 实例
    console.log('a is: ' + this.a)
  }
})
// => "a is: 1"
 

this的指向也是我们初学Vue略感蹊跷的地方。这个this怎么就指向data中数据了呢？

因为我们编写的是选项对象，后被组装给了组件的构造函数。用构造函数实例化组件得到vm实例。在vm实例调用生命周期钩子函数时

// 执行时会用call方法，将this指向vm实例
handlers[i].call(vm)
 

接下来的问题是，vm实例是怎样访问到data的。

Vue先将data变成响应式对象放在vm的_data属性上。再通过代理把每一个值 vm._data.xxx 都代理到 vm.xxx 上。这里的代理是也是通过Object.defineProperty实现的

// 原理如下代码，比如是data里的a属性。
// 用户在写this.a 相当于访问vm.a 也就是调用了下面代码的get：this._data.a
Object.defineProperty(vm, 'a', {
    get: function proxyGetter () {
        return this._data.a
    },
    set: function proxySetter (val) {
        this._data.a = val
    }
})
 

生命周期

beforeCreate：

在此勾子中无法获得props、data 中定义的值，也不能调用 methods 中定义的函数。

在vue-router源码中有这样的代码：

// 我们之所以在写代码时可以this.$router。下面的代码逻辑起了作用。
Vue.mixin({
    beforeCreate () {
        this._routerRoot = this
        this._router = this.$options.router
    }
})

Object.defineProperty(Vue.prototype, '$router', {
    get () { return this._routerRoot._router }
})
 

为vm实例挂一些编写代码时要用的的变量对象，beforeCreate是很合适的。

同理，在Vuex源码中，利用beforeCreate为vm实例添加了$store变量。

created：

如果是需要访问 props、data 等数据的话，就需要使用 created 钩子函数。

在我们写的应用的组件树中，created的执行顺序是从父到子，顺次执行。

mounted：

在真实dom挂载之后，执行mounted。

在我们写的应用的组件树中，不同于created，mounted的执行顺序是从子到父，顺次执行。

destroy：

组件的销毁钩子函数。

在我们写的应用的组件树中，同于mounted，destroy的执行顺序是从子到父，顺次执行。

activated & deactivated

activated 和 deactivated 钩子函数是专门为 keep-alive 组件定制的钩子。

nextTick的细节

nextTick在Web中默认使用的是微任务Promise实现，如果不支持菜使用宏任务（JS事件循环知识点）

研究diff算法时的困惑

之前学习vue diff算法的时候，让我困惑的点在于在比较新旧两个dom树，如果节点是一个组件类型的VNode，会怎么样？

首先要清晰的点是，大部分介绍diff算法的文章，是不考虑组件类型的VNode节点的。所以在看这些文章的时候，只需要将所有节点看成是可以映射成真实dom节点的VNode节点，去考虑其讲解的算法。

这样有利于更专注的研究diff算法本身的逻辑，Vue的diff算法是基于Snabbdom库的，也就是一个没有组件节点的diff算法。

有组件类型Vnode节点时的diff逻辑

在新旧两个VNode树中没有组件类型的VNode节点时，patch是只负责比对两树的不同进而操作真实DOM。但VNode树中有组件类型的的VNode节点时，patch方法的职责变多，如生产组件类型的的VNode节点的子树。

假设一种场景，diff出新树比旧树多了一个Vnode节点，只需在真实dom树上，新增一个有此Vnode映射出的真实dom即可。但当新旧两个VNode树中包含组件类型的VNode节点时，diff出新树比旧树多了一个组件类型的Vnode节点。组件类型的Vnode不能直接映射成真实dom，而是会形成一个子VNode树。这个形成子树的过程跟形成父树一样，产生了一个递归的效果。

所以一个页面的Vnode树，应该是一个大树，里面还嵌套了许多小树，它们的diff逻辑有些情况是互不干扰的，除了在大树中要对小树所在的那个Vnode节点进行新增或删除。

由上面假设的场景可以看出，要捋清整体的vue diff逻辑，还是要花些功夫的，具体的逻辑还是要研究下源码。

算法

在研究diff算法的逻辑时，也能看到到作者的一些算法思想。

首先就是虚拟dom树使用的是树结构。diff的时候对树进行的遍历，虽然对比是逐层对比，但是遍历是用的DFS（深度优先遍历）。

在Vue3.x中，在比对两个Vnode节点的Children变化时，还使用了最长递归子序列算法（leecode上的题目，可以使用贪心+二分法解题），用以保证最少的移动真实dom。