亚洲乱码中文字幕综合,中国熟女仑乱hd,亚洲精品乱拍国产一区二区三区,一本大道卡一卡二卡三乱码全集资源,又粗又黄又硬又爽的免费视频

Vue3生命周期Hooks原理與調(diào)度器Scheduler關(guān)系

 更新時間:2022年07月07日 09:02:18   作者:Cobyte  
這篇文章主要為大家介紹了Vue3生命周期Hooks原理與調(diào)度器Scheduler關(guān)系詳解,有需要的朋友可以借鑒參考下,希望能夠有所幫助,祝大家多多進步,早日升職加薪

寫在最前:本文章的目標

Vue3的生命周期的實現(xiàn)原理是比較簡單的,但要理解整個Vue3的生命周期則還要結(jié)合整個Vue的運行原理,又因為Vue3的一些生命周期的執(zhí)行機制是通過Vue3的調(diào)度器來完成的,所以想要徹底了解Vue3的生命周期原理還必須要結(jié)合Vue3的調(diào)度器的實現(xiàn)原理來理解。同時通過對Vue3的調(diào)度器的理解,從而加深對Vue底層的一些設(shè)計原理和規(guī)則的理解,所以本文章的目標是理解Vue3生命周期Hooks的原理以及通過Vue3生命周期Hooks的運行了解Vue3調(diào)度器(Scheduler)的原理。

Vue3生命周期的實現(xiàn)原理

Vue3的生命周期Hooks函數(shù)的實現(xiàn)原理還是比較簡單的,就是把各個生命周期的函數(shù)掛載或者叫注冊到組件的實例上,然后等到組件運行到某個時刻,再去組件實例上把相應(yīng)的生命周期的函數(shù)取出來執(zhí)行。

下面來看看具體代碼的實現(xiàn)

生命周期類型

// packages/runtime-core/src/component.ts
export const enum LifecycleHooks {
    BEFORE_CREATE = 'bc', // 創(chuàng)建之前
    CREATED = 'c', // 創(chuàng)建
    BEFORE_MOUNT = 'bm', // 掛載之前
    MOUNTED = 'm', // 掛載之后
    BEFORE_UPDATE = 'bu', // 更新之前
    UPDATED = 'u', // 更新之后
    BEFORE_UNMOUNT = 'bum', // 卸載之前
    UNMOUNTED = 'um', // 卸載之后
	// ...
}

各個生命周期Hooks函數(shù)的創(chuàng)建

// packages/runtime-core/src/apiLifecycle.ts
export const onBeforeMount = createHook(LifecycleHooks.BEFORE_MOUNT)
export const onMounted = createHook(LifecycleHooks.MOUNTED)
export const onBeforeUpdate = createHook(LifecycleHooks.BEFORE_UPDATE)
export const onUpdated = createHook(LifecycleHooks.UPDATED)
export const onBeforeUnmount = createHook(LifecycleHooks.BEFORE_UNMOUNT)
export const onUnmounted = createHook(LifecycleHooks.UNMOUNTED)

可以看到各個生命周期的Hooks函數(shù)是通過createHook這個函數(shù)創(chuàng)建的

創(chuàng)建生命周期函數(shù)createHook

// packages/runtime-core/src/apiLifecycle.ts
export const createHook = (lifecycle) => (hook, target = currentInstance) => injectHook(lifecycle, hook, target)

createHook是一個閉包函數(shù),通過閉包緩存當前是屬于哪個生命周期的Hooks,target表示該生命周期Hooks函數(shù)被綁定到哪個組件實例上,默認是當前工作的組件實例。createHook底層又調(diào)用了一個injectHook的函數(shù),那么下面我們繼續(xù)來看看這個injectHook函數(shù)。

injectHook函數(shù)

injectHook是一個閉包函數(shù),通過閉包緩存綁定對應(yīng)生命周期Hooks到對應(yīng)的組件實例上。

// packages/runtime-core/src/apiLifecycle.ts
export function injectHook(type, hook, target) {
    if(target) {
        // 把各個生命周期的Hooks函數(shù)掛載到組件實例上,并且是一個數(shù)組,因為可能你會多次調(diào)用同一個組件的同一個生命周期函數(shù)
        const hooks = target[type] || (target[type] = [])
        // 把生命周期函數(shù)進行包裝并且把包裝函數(shù)緩存在__weh上
        const wrappedHook =
        hook.__weh ||
        (hook.__weh = (...args: unknown[]) => {
          if (target.isUnmounted) {
            return
          }
            // 當生命周期調(diào)用時 保證currentInstance是正確的
            setCurrentInstance(target)
            // 執(zhí)行生命周期Hooks函數(shù)
            const  res = args ? hook(...args) : hook()
            unsetCurrentInstance()
          return res
        })
        // 把生命周期的包裝函數(shù)綁定到組件實例對應(yīng)的hooks上
        hooks.push(wrappedHook)
        // 返回包裝函數(shù)
        return wrappedHook
    }
}

生命周期Hooks的調(diào)用

instance.update = effect(() => {
    if (!instance.isMounted) {
        const { bm, m } = instance
        // 生命周期:beforeMount hook
        if (bm) {
            invokeArrayFns(bm)
        }
        // 組件初始化的時候會執(zhí)行這里
        // 為什么要在這里調(diào)用 render 函數(shù)呢
        // 是因為在 effect 內(nèi)調(diào)用 render 才能觸發(fā)依賴收集
        // 等到后面響應(yīng)式的值變更后會再次觸發(fā)這個函數(shù)  
        const subTree = (instance.subTree = renderComponentRoot(instance))
        patch(null, subTree, container, instance, anchor)
        instance.vnode.el = subTree.el 
        instance.isMounted = true
        // 生命周期:mounted
        if(m) {
            // mounted需要通過Scheduler的函數(shù)來調(diào)用
            queuePostFlushCb(m)
        }
    } else {
        // 響應(yīng)式的值變更后會從這里執(zhí)行邏輯
        // 主要就是拿到新的 vnode ,然后和之前的 vnode 進行對比
        // 拿到最新的 subTree
        const { bu, u, next, vnode } = instance
        // 如果有 next 的話, 說明需要更新組件的數(shù)據(jù)(props,slots 等)
        // 先更新組件的數(shù)據(jù),然后更新完成后,在繼續(xù)對比當前組件的子元素
        if(next) {
            next.el = vnode.el
            updateComponentPreRender(instance, next)
        }
        // 生命周期:beforeUpdate hook
        if (bu) {
            invokeArrayFns(bu)
        }
        const subTree = renderComponentRoot(instance)
        // 替換之前的 subTree
        const prevSubTree = instance.subTree
        instance.subTree = subTree
        // 用舊的 vnode 和新的 vnode 交給 patch 來處理
        patch(prevSubTree, subTree, container, instance, anchor)
        // 生命周期:updated hook
        if (u) {
            // updated 需要通過Scheduler的函數(shù)來調(diào)用
            queuePostFlushCb(u)
        }
    }
}, {
    scheduler() {
        queueJobs(instance.update)
    }
})

上面這個是Vue3組件實例化之后,通過effect包裝一個更新的副作用函數(shù)來和響應(yīng)式數(shù)據(jù)進行依賴收集。在這個副作用函數(shù)里面有兩個分支,第一個是組件掛載之前執(zhí)行的,也就是生命周期函數(shù)beforeMount和mount調(diào)用的地方,第二個分支是組件掛載之后更新的時候執(zhí)行的,在這里就是生命周期函數(shù)beforeUpdate和updated調(diào)用的地方。 具體就是在掛載之前,還沒生成虛擬DOM之前就執(zhí)行beforeMount函數(shù),之后則去生成虛擬DOM經(jīng)過patch之后,組件已經(jīng)被掛載到頁面上了,也就是頁面上顯示視圖了,這個時候就去執(zhí)行mount函數(shù);在更新的時候,還沒獲取更新之后的虛擬DOM之前執(zhí)行beforeUpdate,然后去獲取更新之后的虛擬DOM,然后再去patch,更新視圖,之后就執(zhí)行updated。 需要注意的是beforeMount和beforeUpdate是同步執(zhí)行的,都是通過invokeArrayFns來調(diào)用的。 invokeArrayFns函數(shù)

export const invokeArrayFns = (fns: Function[], arg?: any) => {
  for (let i = 0; i < fns.length; i++) {
    fns[i](arg)
  }
}

組件掛載和更新則是異步的,需要通過Scheduler來處理。

Vue3調(diào)度器(Scheduler)原理

在Vue3的一些API,例如:組件的生命周期API、watch API、組件更新的回調(diào)函數(shù)都不是立即執(zhí)行的,而是放到異步任務(wù)隊列里面,然后按一定的規(guī)則進行執(zhí)行的,比如說任務(wù)隊列里面同時存在,watch的任務(wù),組件更新的任務(wù),生命周期的任務(wù),它的執(zhí)行順序是怎么樣的呢?這個就是由調(diào)度器的調(diào)度算法決定,同時調(diào)度算法只調(diào)度執(zhí)行的順序,不負責具體的執(zhí)行。這樣設(shè)計的好處就是即便將來Vue3增加新的異步回調(diào)API,也不需要修改調(diào)度算法,可以極大的減少 Vue API 和 隊列間耦合。 Vue3的Scheduler提供了三個入列方式的API:

queuePreFlushCb API: 加入 Pre 隊列 組件更新前執(zhí)行

export function queuePreFlushCb(cb: SchedulerJob) {
  queueCb(cb, activePreFlushCbs, pendingPreFlushCbs, preFlushIndex)
}

queueJob API: 加入 queue 隊列 組件更新執(zhí)行

export function queueJob(job: SchedulerJob) {
}

queuePostFlushCb API: 加入 Post 隊列 組件更新后執(zhí)行

export function queuePostFlushCb(cb: SchedulerJobs) {
  queueCb(cb, activePostFlushCbs, pendingPostFlushCbs, postFlushIndex)
}

由于Vue3只提供了入列方式的API并沒有提供出列方式的API,所以我們只能控制何時入列,而何時出列則由Vue3調(diào)度器本身控制。

那么Vue3調(diào)度器如何控制出列方式呢?其實也很簡單。

function flushJobs(seen?) {
    isFlushPending = false
    // 組件更新前隊列執(zhí)行
    flushPreFlushCbs(seen)
    try{
        // 組件更新隊列執(zhí)行
        let job
        while (job = queue.shift()) {
            job && job()
        }
    } finally {
        // 組件更新后隊列執(zhí)行
        flushPostFlushCbs(seen)
        // 如果在執(zhí)行異步任務(wù)的過程中又產(chǎn)生了新的隊列,那么則繼續(xù)回調(diào)執(zhí)行
        if (
            queue.length ||
            pendingPreFlushCbs.length ||
            pendingPostFlushCbs.length
        ) {
            flushJobs(seen)
        }
    }
}

Vue父子組件的生命周期的執(zhí)行順序

這里有兩個概念需要厘清的概念,一:父子組件的執(zhí)行順序,二:父子組件生命周期的執(zhí)行順序。這兩個是不一樣的

父子組件的執(zhí)行順序

這個是先執(zhí)行父組件再執(zhí)行子組件,先父組件實例化,然后去獲取父組件的虛擬DOM之后在patch的過程中,如果父組件的虛擬DOM中存在組件類型的虛擬DOM也就是子組件,那么在patch的分支中就會去走組件初始化的流程,如此循環(huán)。

父子組件生命周期的執(zhí)行順序

父子組件生命周期的執(zhí)行順序是在父子組件的執(zhí)行順序下通過調(diào)度算法按Vue的規(guī)則進行執(zhí)行的。首先父組件先實例化進行執(zhí)行,通過上面的生命周期的調(diào)用說明,我們可以知道,父組件在更新函數(shù)update第一次執(zhí)行,也就是組件初始化的時候,先執(zhí)行父組件的beforeMount,然后去獲取父組件的虛擬DOM,然后在patch的過程中遇到虛擬節(jié)點是組件類型的時候,就又會去走組件初始化的流程,這個時候其實就是子組件初始化,那么之后子組件也需要走一遍組件的所有流程,子組件在更新update第一次執(zhí)行的時候,先執(zhí)行子組件的beforeMount,再去獲取子組件的虛擬DOM,然后patch子組件的虛擬DOM,如果過程中又遇到節(jié)點是組件類型的話,又去走一遍組件初始化的流程,直到子組件patch完成,然后執(zhí)行子組件的mounted生命周期函數(shù),接著回到父組件的執(zhí)行棧,執(zhí)行父組件的mounted生命周期。

所以在初始化創(chuàng)建的時候,是深度遞歸創(chuàng)建子組件的過程,父子組件的生命周期的執(zhí)行順序是:

  • 父組件 -> beforeMount
  • 子組件 -> beforeMount
  • 子組件 -> mounted
  • 父組件 -> mounted

父子組件更新順序同樣是深度遞歸執(zhí)行的過程:

  • 如果父子組件沒通過props傳遞數(shù)據(jù),那么更新的時候,就各自執(zhí)行各自的更新生命周期函數(shù)。
  • 如果父子組件存在通過props傳遞數(shù)據(jù)的話,就必須先更新父組件,才能更新子組件。因為父組件 DOM 更新前,需要修改子組件的 props,子組件的 props 才是正確的值。

下面我們來看源碼

if (next) {
    next.el = vnode.el
    // 在組件更新前,先更新一些數(shù)據(jù)
    updateComponentPreRender(instance, next, optimized)
} else {
    next = vnode
}

例如更新props,更新slots

  const updateComponentPreRender = (
    instance: ComponentInternalInstance,
    nextVNode: VNode,
    optimized: boolean
  ) => {
    nextVNode.component = instance
    const prevProps = instance.vnode.props
    instance.vnode = nextVNode
    instance.next = null
    // 更新props
    updateProps(instance, nextVNode.props, prevProps, optimized)
    // 更新slots
    updateSlots(instance, nextVNode.children, optimized)
	// ...
  }

所以在父子組件更新的時候,父子組件的生命周期執(zhí)行順序是:

  • 父組件 -> beforeUpdate
  • 子組件 -> beforeUpdate
  • 子組件 -> updated
  • 父組件 -> updated

同樣卸載的時候父子組件也是深度遞歸遍歷執(zhí)行的過程:

  • 父組件 -> beforeUnmount
  • 子組件 -> beforeUnmount
  • 子組件 -> unmounted
  • 父組件 -> unmounted

組件卸載的時候,是在卸載些什么呢?

組件卸載的時候主要是卸載模版引用,清除effect里面保存的相關(guān)組件的更新函數(shù)的副作用函數(shù),如果是緩存組件,則清除相關(guān)緩存,最后去移除真實DOM上相關(guān)節(jié)點。

另外組件 DOM 更新(instance.update)是有保存在調(diào)度器的任務(wù)隊列中的,組件卸載的時候,也需要把相關(guān)的組件更新(instance.update)設(shè)置失效。

在源碼的unmountComponent函數(shù)中,有這么一段:

if (update) {
    // 把組件更新函數(shù)的active設(shè)置false
    update.active = false
    unmount(subTree, instance, parentSuspense, doRemove)
}

然后在Scheduler執(zhí)行queue隊列任務(wù)的時候,那些job的active為false的則不執(zhí)行

const job = queue[flushIndex]
// 那些job的active為false的則不執(zhí)行
if (job && job.active !== false) {
    callWithErrorHandling(job, null, ErrorCodes.SCHEDULER)
}

那么組件 DOM 更新(instance.update)什么時候會被刪除呢?

在源碼的updateComponent函數(shù)可以找到刪除instance.update的設(shè)置

invalidateJob(instance.update)
// 立即執(zhí)行更新任務(wù)
instance.update()

調(diào)度器刪除任務(wù)

export function invalidateJob(job: SchedulerJob) {
  // 找到 job 的索引
  const i = queue.indexOf(job)
  if (i > flushIndex) {
    // 刪除 Job
    queue.splice(i, 1)
  }
}

由此我們可以得知在一個組件更新的時候,會先把該組件在調(diào)度器里的更新任務(wù)先刪除。因為組件更新也是一個遞歸執(zhí)行更新的過程,在遞歸的過程中執(zhí)行了子組件的更新,那么調(diào)度器的任務(wù)隊列里面的子組件更新任務(wù)就不需要再執(zhí)行了,所以就要刪除掉,將來子組件依賴的響應(yīng)式數(shù)據(jù)發(fā)生了更新,那么則重新把子組件的更新任務(wù)放到調(diào)度器的任務(wù)隊列里去。

組件更新的調(diào)度器里的隊列任務(wù)的失效與刪除的區(qū)別

通過上述組件卸載的介紹我們可以總結(jié)一下組件更新的調(diào)度器里的隊列任務(wù)的失效與刪除的區(qū)別

失效

  • 組件卸載時,將 Job 設(shè)置為失效,Job 從隊列中取出時,不再執(zhí)行
  • 不能再次加入隊列,因為會被去重
  • 被卸載的組件,無論它依賴的響應(yīng)式變量如何更新,該組件都不會更新了

刪除

  • 組件更新時,刪除該組件在調(diào)度器任務(wù)隊列中的 Job
  • 可以再次加入隊列
  • 刪除任務(wù),因為已經(jīng)更新過了,不需要重復更新。 如果依賴的響應(yīng)式變量再次被修改,仍然需要加入調(diào)度器的任務(wù)隊列,等待更新

父子組件執(zhí)行順序與調(diào)度器的關(guān)系

假設(shè)有有這樣一個場景,有一對父子組件,子組件使用watch API監(jiān)聽某個子組件的響應(yīng)式數(shù)據(jù)發(fā)生改變之后,然后去修改了N個父組件的響應(yīng)式數(shù)據(jù)。那么N個父組件的更新函數(shù)都將被放到調(diào)度器的任務(wù)隊列中等待執(zhí)行。這種情況調(diào)度器怎么確保最頂層的父組件的更新函數(shù)最先執(zhí)行呢?

我們先看看調(diào)度器的任務(wù)隊列里的Job的數(shù)據(jù)結(jié)構(gòu)

export interface SchedulerJob extends Function {
  id?: number  // 用于對隊列中的 job 進行排序,id 小的先執(zhí)行
  active?: boolean
  computed?: boolean
  allowRecurse?: boolean 
  ownerInstance?: ComponentInternalInstance	
}

Job是一個函數(shù),并且?guī)в幸恍傩浴F渲衖d,表示優(yōu)先級,用于實現(xiàn)隊列插隊,id 小的先執(zhí)行,active通過上文我們可以知道active表示 Job 是否有效,失效的 Job 不執(zhí)行,如組件卸載會導致 Job 失效。

調(diào)度器任務(wù)隊列的數(shù)據(jù)結(jié)構(gòu)

const queue: SchedulerJob[] = []

是一個數(shù)組

調(diào)度器任務(wù)隊列的執(zhí)行

// 按任務(wù)id大小排序
queue.sort((a, b) => getId(a) - getId(b))
try {
    for (flushIndex = 0; flushIndex < queue.length; flushIndex++) {
        const job = queue[flushIndex]
        if (job && job.active !== false) {
            // 使用帶有 Vue 內(nèi)部的錯誤處理函數(shù)執(zhí)行job
            callWithErrorHandling(job, null, ErrorCodes.SCHEDULER)
        }
    }
} finally {
    // 清空 queue 隊列
    flushIndex = 0
    queue.length = 0
}

那么又怎么確保父組件的更新函數(shù)的任務(wù)id是最小的呢?

通過查看源碼我們可以看在創(chuàng)建組件實例的createComponentInstance函數(shù)中有一個uid的屬性,并且它的初始值為0,后續(xù)則++

let uid = 0 // 初始化為0
export function createComponentInstance(
  vnode
  parent
  suspense
) {
  const instance: ComponentInternalInstance = {
    uid: uid++,
   // ...   
  }

然后在創(chuàng)建組件更新函數(shù)的時候可以看到,組件更新函數(shù)的id就是該組件實例的uid

const update = (instance.update = effect.run.bind(effect) as SchedulerJob)
update.id = instance.uid

組件創(chuàng)建的過程是深度遞歸創(chuàng)建子組件的過程,所以最先的父組件是0,后面的子組件則一路++上去,這樣就確保了子組件的更新函數(shù)的任務(wù)id是一定大于父組件更新函數(shù)的id的。所以當調(diào)度器的任務(wù)隊列里面同時存在很多組件的更新函數(shù)的時候,通過優(yōu)先級排序,就可以確保一定父組件的更新函數(shù)最先執(zhí)行了。

當前中途也可以進行插隊

export function queueJob(job: SchedulerJob) {
	// 沒有id的則push到最后
    if (job.id == null) {
      queue.push(job)
    } else {
      // 進行插隊處理
      queue.splice(findInsertionIndex(job.id), 0, job)
    }
    queueFlush()
}

Hooks的本質(zhì)

最后探討一下Hooks的本質(zhì)

Vue的Hooks設(shè)計是從React的Hooks那里借鑒過來的,React的Hooks的本質(zhì)就是把狀態(tài)變量、副作用函數(shù)存到函數(shù)組件的fiber對象上,等到將來狀態(tài)變量發(fā)生改變的時候,相關(guān)的函數(shù)組件fiber就重新進行更新。Vue3這邊的實現(xiàn)原理也類似,通過上面的生命周期的Hooks實現(xiàn)原理,我們可以知道Vue3的生命周期的Hooks是綁定到具體的組件實例上,而狀態(tài)變量,則因為Vue的變量是響應(yīng)式的,狀態(tài)變量會通過effect和具體的組件更新函數(shù)進行依賴收集,然后進行綁定,將來狀態(tài)變量發(fā)生改變的時候,相應(yīng)的組件更新函數(shù)會重新進入調(diào)度器的任務(wù)隊列進行調(diào)度執(zhí)行。

所以Hooks的本質(zhì)就是讓那些狀態(tài)變量或生命周期函數(shù)和組件綁定起來,組件運行到相應(yīng)時刻執(zhí)行相應(yīng)綁定的生命周期函數(shù),那些綁定的變量發(fā)生改變的時候,相應(yīng)的組件也重新進行更新。

最后

下一篇準備寫一下watch API的實現(xiàn)原理,同時watch API也需要和調(diào)度器結(jié)合進行理解,只有相互串聯(lián)理解才可以把Vue3底層設(shè)計和實現(xiàn)原理理解得更加透切一些。

最后推薦一個學習vue3源碼的庫,它是基于崔效瑞老師的開源庫mini-vue而來,在mini-vue的基礎(chǔ)上實現(xiàn)更多的vue3核心功能,用于深入學習 vue3, 讓你更輕松地理解 vue3 的核心邏輯。

源碼地址 https://github.com/amebyte/mini-vue3-plus

以上就是Vue3生命周期Hooks原理與調(diào)度器Scheduler關(guān)系的詳細內(nèi)容,更多關(guān)于Vue3 Hooks與Scheduler關(guān)系的資料請關(guān)注腳本之家其它相關(guān)文章!

相關(guān)文章

最新評論