前言
之前在 Component 組件 の Angular Component vs Custom Elements?文章中,我們有學(xué)習(xí)過(guò)幾個(gè)基礎(chǔ)的 Lifecycle Hooks。
比如?OnChanges、OnInit、AfterViewInit、OnDestroy,但那篇只是微微帶過(guò)而已。
這篇讓我們來(lái)深入理解 Angular 的?Lifecycle Hooks。
?文章來(lái)源地址http://www.zghlxwxcb.cn/news/detail-837831.html
介紹
在?Component 組件 の Dependency Injection & NodeInjector?文章中,我們看見了組件從無(wú)到有的創(chuàng)建與渲染過(guò)程。
整個(gè)過(guò)程可以被分解成多個(gè)階段,每一個(gè)階段的組件都處于不同的形態(tài)。
比如
A 階段,組件只是個(gè) Definition。
B 階段,組件已經(jīng)被實(shí)例化,但是 Template 中的子組件尚未被實(shí)例化。
C 階段,ViewModel 已經(jīng)更新到 DOM 上。
等等
組件生命周期鉤子的目的就是讓我們有機(jī)會(huì)去攔截上面這些階段,然后對(duì)組件做一些事情。
Angular 一共提供了 8 個(gè)鉤子,它們是(排名不分先后):
- OnInit
- OnChanges
- DoCheck
- AfterContentInit
- AfterContentChecked
- AfterViewInit
- AfterViewChecked
- OnDestroy
如果加上組件 constructor 那就是 9 個(gè)鉤子。
?
Constructor 階段
想要深入理解組件生命周期鉤子,最簡(jiǎn)單的方法自然是逛源碼咯。
經(jīng)歷過(guò)了?Change Detection 和?NodeInjector 兩篇文章。我相信大家對(duì) bootstrapApplication 函數(shù)已經(jīng)不陌生了,那我們直接進(jìn)入重點(diǎn)吧。
組件實(shí)例化發(fā)生在什么時(shí)候?
bootstrapApplication 有兩大環(huán)節(jié),一個(gè)是 create,一個(gè)是 update。
所有的組件都會(huì)在 create 階段被實(shí)例化。
ApplicationRef.bootstrap 方法中有這么一段
這里的重點(diǎn)是,所有組件(App 和其后裔)實(shí)例化都是在 create 階段完成的。在進(jìn)入 update 階段之前,所有組件都是已經(jīng)實(shí)例化好的了。
我們進(jìn)入?ComponentFactory.create 方法看看 create 階段實(shí)例化組件的細(xì)節(jié)。
renderView 函數(shù)的源碼在 render.ts
所謂的 render 就是執(zhí)行這個(gè)組件的 template 方法,這個(gè)方法會(huì)實(shí)例化所有的子組件。
這里的重點(diǎn)是,先實(shí)例化完所有子組件,然后才繼續(xù)逐個(gè) render 子組件。
renderChildComponents 函數(shù)
renderComponent 函數(shù)
組件實(shí)例化的順序
依據(jù)上面的源碼,它有 3 個(gè)重要的步驟
-
實(shí)例化組件
-
render 組件 (也就是執(zhí)行組件 template 方法,這方法會(huì)實(shí)例化所有子組件)。
-
所有子組件實(shí)例化好了后,再逐個(gè) render 子組件,這里就開始遞歸了,一直到所有后裔組件實(shí)例化完成。
我們來(lái)看個(gè)復(fù)雜點(diǎn)的例子
相同顏色表示它們?cè)谕粋€(gè)組件 Template 里,號(hào)碼表示組件被實(shí)例化的順序。
我們需要搞清楚什么時(shí)候在同一層,什么時(shí)候去下一層。
1. 相同顏色的,一定是連貫的順序
因?yàn)閷?shí)例化子組件時(shí),是不會(huì)進(jìn)入下一層孫組件的,只有等到所有子組件實(shí)例化好后,才會(huì)往下一層孫組件走。
2. 路線圖
?
constructor 階段可以做什么?
constructor 的特別之處在于它是 injection context,所以它可以使用 inject 函數(shù)。
其它 Lifecycle Hooks 都不行哦。
我們通常會(huì)在 constructor 階段注入組件需要的 Service,把它們存起來(lái),供之后使用。
constructor 階段不可以做什么?
constructor 階段,@Input 屬性值還沒有被填寫,它是不可用的。
?
8 大組件生命周期鉤子 Overview
我們先 overview 這 8 個(gè)生命周期鉤子:
-
8 個(gè) Lifecycle Hooks 全部發(fā)生在 refreshView 函數(shù)中,除了 DestroyHooks。(大名鼎鼎的 refreshView 函數(shù)在 Change Detection?文章中就介紹過(guò)了,不熟悉的請(qǐng)回去溫習(xí))
-
refreshView 會(huì)遍歷所有組件,只要中途沒有中斷,所有組件的 Lifecycle Hooks 都有機(jī)會(huì)觸發(fā),當(dāng)然如果中途斷了,那剩余的組件就不會(huì)觸發(fā)任何 Lifecycle Hooks 了。
-
OnInit、AfterContentInit、AfterViewInit 只會(huì)在第一次 refreshView 時(shí)觸發(fā),往后就不再觸發(fā)了。
-
OnChanges 在每一次 refreshView 時(shí),只要有 @Input 并且值發(fā)生了變化就會(huì)觸發(fā) (第一次賦值也算值變化),如果沒有變化就不會(huì)觸發(fā)。
-
DoCheck、ngAfterContentChecked、ngAfterViewChecked 在每一次 refreshView 都會(huì)觸發(fā)。
-
OnDestroy 只會(huì)在組件被銷毀時(shí)觸發(fā),也只會(huì)觸發(fā)一次。(我們還沒有學(xué)到如何銷毀組件,這個(gè)之后在 Dynamic Component 章節(jié)才會(huì)教)
?
PreOrderHooks (OnChanges, OnInit, DoCheck)
8 個(gè) Lifecycle Hooks 全部發(fā)生在 refreshView 函數(shù)中,處了 DestroyHooks,那我們就從 refreshView 函數(shù)源碼開始吧。
下面會(huì)有 4 中情況,我會(huì)一起講,雖然可能有點(diǎn)亂,但沒辦法,分開講篇幅會(huì)很長(zhǎng),很啰嗦。
-
refreshView(rootLView) 從 Root LView 開始
-
refreshView(appLView) 從 App LView 開始
-
第一次 refreshView
-
第 n 次 refreshView
refreshView 函數(shù)?の template 方法
refreshView 源碼在這里?change_detection.ts
App 組件長(zhǎng)這樣
app.component.js
refreshView 第一件事是去執(zhí)行 LView 的 template 方法,這個(gè)方法指的是組件 Definition 中的 template 方法 (上圖)。
這個(gè) template 方法,我們已經(jīng)研究過(guò)許多次了。
create mode 主要負(fù)責(zé)實(shí)例化子組件,創(chuàng)建它們的 TNode、TView、LView、NodeInjector 等等。
update mode 主要負(fù)責(zé)把 ViewModel 和 binding syntax 結(jié)合,也就是 "更新 DOM" 啦。
此外 update mode 里還多了 2 個(gè)以前沒有學(xué)過(guò)的新代碼???property 和???advance,我們來(lái)看看它們是做什么的。
??property 函數(shù)
??property 的作用是把 ViewModel binding 到子組件的 @Input 屬性上。
ctx 就是組件實(shí)例,也就是所謂的 ViewModel 啦。
??advance 函數(shù)
??advance 有 2 個(gè)功能,一個(gè)是移位。一個(gè)是執(zhí)行 PreOrderHooks。
移位
移位的概念是這樣的:
假設(shè) Template 長(zhǎng)這樣
compile 以后
有箭頭的地方是有 binding syntax 的。坐標(biāo)是 index 1、8、10、17。
它的過(guò)程是:
移位到 index 1 > 更新 DOM >
移位到 index 8 > 填 @Input 給 C1 組件 >
移位到 index 10 > 更新 DOM >
移位到 index 17 >?填 @Input 給 C2 組件。
PreOrderHooks
??advance 函數(shù)源碼在這里 advance.ts
在移位之前,它會(huì)先執(zhí)行 PreOrderHooks。
如果是第 1 次 refreshView,那會(huì)執(zhí)行??tView.preOrderHooks。
如果是第 n 次 refreshView,那會(huì)執(zhí)行?tView.preOrderCheckHooks。
我們來(lái)看看 TView 里的 preOrderHooks 和?preOrderCheckHooks 是指哪一些 Hooks。
getNodeInjectable 主要任務(wù)是實(shí)例化組件,然后它會(huì)把組件的 PreOrderHooks register to TView。
這里的重點(diǎn)是 TView 指的是誰(shuí)?
假設(shè),當(dāng)前實(shí)例化的組件是 C1 組件,那 C1 的 PreOrderHooks 會(huì)被 regsiter 到 C1 的 parent TView,也就是 App TView。
同理,如果當(dāng)前實(shí)例化的組件是 App 組件,那 App 的 PreOrderHooks 會(huì)被 register 到 App 的 parent TView,也就是 Root TView。
這個(gè)概念和組件 providers 是一樣的,組件 providers 也是保存到 parent TView 中。
舉例
下圖是 C1 和 C2 組件,它們都有 OnInit Hook。
下圖是 App Template
C1 和 C2 組件的 OnInit Hook 會(huì)被 register 到它們的 parent TView(也就是 App TView)。
下圖是 App TView
里面有 2 個(gè) OnInit Hook。其它位置的號(hào)碼,我們不需要理會(huì)。
小總結(jié)
refreshView 會(huì)執(zhí)行組件 template 方法 (update mode)
template 方法內(nèi)有???property 和???advance 函數(shù)。
??property 負(fù)責(zé)填寫子組件的 @Input
??advance 負(fù)責(zé)執(zhí)行子組件的 PreOrderHooks 和移位。
回到 App template 方法
上面有 2 個(gè)重點(diǎn)
-
當(dāng)子組件執(zhí)行 PreOrderHooks 時(shí),父組件的 template 方法是還沒有執(zhí)行完的。
比如上面,C1 OnInit 時(shí),App 還沒有更新 value3 到 DOM,也還沒有填寫 value4 到 C2 的 @Input。
-
template 方法的結(jié)尾不是 ??advance。
所以當(dāng) template 方法執(zhí)行完,C1 PreOrderHooks 是執(zhí)行了的,但是 C2?PreOrderHooks 卻還沒有執(zhí)行。
C2 好像是被落下了。
refreshView 函數(shù)?の?PreOrderHooks
上面提到,C2?PreOrderHooks 被落下了。我們繼續(xù)看 refreshView 函數(shù)。
在執(zhí)行完組件 template 方法后,接著就執(zhí)行 PreOrderHooks 了。這個(gè)環(huán)節(jié)和???advance 里的幾乎是一樣的,只是它沒有指定 index。
至此,所有子組件的?PreOrderHooks 都執(zhí)行完了。
PreOrderHooks 可以 / 不可以做什么?
PreOrderHooks 階段,組件(e.g. C1)所有的 @Input 都已經(jīng)賦值。
此時(shí)我們可以修改組件的屬性,因?yàn)榻M件的 template 還沒有執(zhí)行。
但是,最好不要修改父組件(App)的屬性了,因?yàn)檫@個(gè)時(shí)候,父組件的 template 已經(jīng)開始執(zhí)行了,
某些屬性或許已經(jīng)被用于 DOM 更新了。
總之,best practice 是不要在 PreOrderHooks 里修改祖先組件的屬性。
OnChanges 階段可以做什么?
OnChanges 類似于 Custom Elements 的 attributeChangedCallback。
在每一次 refreshView 時(shí),只要有 @Input 并且值發(fā)生了變化就會(huì)觸發(fā) (第一次賦值也算值變化),如果沒有變化就不會(huì)觸發(fā)。
export class C1Component implements OnChanges { @Input() value!: string; ngOnChanges(changes: SimpleChanges): void { const valueChange = changes['value']; if (valueChange.firstChange) { console.log('before after', [ valueChange.previousValue, // undefined valueChange.currentValue, // value 2 ]); } } }
OnInit 階段可以做什么?
我們大部分邏輯代碼都會(huì)寫在這里。
DoCheck 階段可以做什么?
之前在 Change Detection 文章中講解過(guò)了,這里就不復(fù)述了。
?
ContentHooks (AfterContentInit, AfterContentChecked)
Content 指的是?Content Projection?(a.k.a slot / transclude / ng-content)。
refreshView 函數(shù) の ContentHooks
同樣是 refreshView 函數(shù),在執(zhí)行組件 template 方法 > PreOrderHooks 之后,就到了 ContentHooks。
detectChangesInEmbeddedViews 是 Dynamic Component 章節(jié)的內(nèi)容,之后會(huì)教。
refreshContentQueries 是 Query Elements 章節(jié)的內(nèi)容,之后會(huì)教。
和 PreOrderHooks 一樣,ContentHooks 也都放在 TView 里。
我們看看 tView.contentHooks 是什么時(shí)候被賦值的。
下圖是 App Template
compile 以后
子組件的 ContentHooks 是在???elementEnd 函數(shù)中被 register 到 TView 的。
注:??element 函數(shù)結(jié)尾也是有調(diào)用???elementEnd 哦
??elementEnd 函數(shù)
??elementEnd 函數(shù)源碼在 element.ts
registerPostOrderHooks 函數(shù)源碼在 hooks.ts
PostOrderHooks Registration 小細(xì)節(jié)
1. PostOrderHooks 包含 ContentHooks,ViewHooks 還有 DestroyHook,它們都是在這個(gè)環(huán)節(jié) register 的。
2. Register PreOrderHooks 是發(fā)生在單個(gè)組件或指令實(shí)例化后,所以每一次只 register 一個(gè)組件或指令。
Register PostOrderHooks 是發(fā)生在 1 個(gè) TNode 內(nèi)的組件和指令全部實(shí)例化之后,所以每一次是把 TNode 內(nèi)的組件和指令全部都 register。
3. Register PreOrderHooks 的順序
順序是 C2 -> C1 -> C3?
和 PreOrderHooks 的區(qū)別
PostOrderHooks 和 PreOrderHooks 非常相似,都是在組件 template 方法 create mode 階段把 Hooks register 到 TView。
都是在 template 方法 update mode 時(shí)執(zhí)行。
比較大的區(qū)別是 register 的順序
PreOrderHooks 很簡(jiǎn)單,上到下,組件或指令實(shí)例化之后就 register。
PostOrderHooks 則多了一個(gè)里到外的概念,因?yàn)樗且罁?jù) ??elementEnd 的位置。
比如上圖,從上往下看,第一個(gè) element end 是 </app-c2>,然后是 </app-c1> 最后才是 </app-c3>,所以順序是 C2 > C1 > C3。
另外一點(diǎn)是,子組件(e.g. C1)PreOrderHooks 執(zhí)行時(shí),組件(App)template 方法是還沒有執(zhí)行完的,它有一半一半的概念,
PostOrderHooks 就沒有這個(gè)概念,在子組件(C1)PostOrderHooks 執(zhí)行時(shí),(App)template 方法是已經(jīng)執(zhí)行完的了。
PostOrderHooks 可以 / 不可以做什么?
絕對(duì)不可以修改祖先組件的屬性,因?yàn)樽嫦冉M件的 template 方法都已經(jīng)執(zhí)行完了,DOM 都更新完了。
ContentHooks 階段可以做什么?
提醒:ngAfterContentInit 只會(huì)觸發(fā) 1 次,AfterContentChecked? 每一次 refreshView 都會(huì)觸發(fā)。
ngAfterContentInit 階段我們可以 Query Content,比如 C1 組件 query C2 組件。(注:Query Elements 下一篇才會(huì)教)
然后可以修改 C2 的屬性,因?yàn)檫@時(shí) C2 還沒有執(zhí)行 template 方法,DOM 還沒有更新,所以還能改。
關(guān)于 Query Content 的細(xì)節(jié),下一篇會(huì)教,這里我們只要知道這個(gè) Hooks 可以用于處理?Content Projection 里的內(nèi)容就好了。
?
ViewHooks (AfterViewInit, AfterViewChecked)
View 指的是 LView。
refreshView 函數(shù) の ViewHooks
同樣是 refreshView 函數(shù),在執(zhí)行組件 template 方法 > PreOrderHooks > ContentHooks 之后就到了 ViewHooks。
executeViewQueryFn 是 Query Elements 章節(jié)的內(nèi)容,之后會(huì)教。
ViewHooks register to TView 這個(gè)過(guò)程,上面講解 ContentHooks 時(shí)已經(jīng)講過(guò)了,它們都屬于 PostOrderHooks,都是在???elementEnd 時(shí)一起 register 的。
和 ContentHooks 的區(qū)別
最重要的一點(diǎn)是,在執(zhí)行子組件 ViewHooks 前,會(huì)先遞歸 refreshView(子組件)
例子說(shuō)明
下圖是 App Template
PreOrderHooks 的順序是:C1 > C2 > C3
這時(shí) App template 方法已經(jīng)執(zhí)行完了,App DOM 已經(jīng)更新。
ContentHooks 的順序是:C2 > C1 > C3
這時(shí) C1、C2、C3 的 template 方法都還沒有執(zhí)行,DOM 還沒有更新。
在執(zhí)行 ViewHooks 之前,先遞歸 refreshView(C1)、refreshView(C2)、refreshView(C3)
假設(shè) C1、C2、C3 Template 里都沒有子組件,那它們 TView 自然也沒有 Hooks,那執(zhí)行完 template 方法后就返回到了?refreshView(App)。
接著就到執(zhí)行 ViewHooks 了,ViewHooks?的順序和 ContentHooks 一樣 (因?yàn)樗鼈兪且黄?register 的):C2 > C1 > C3
結(jié)束
ViewHooks 階段可以做什么?
當(dāng)一個(gè)組件的 ViewHooks 觸發(fā)時(shí),它的祖先,它自己,它的后裔,所有組件的 template 方法都已經(jīng)執(zhí)行完了,DOM 也更新完了。
通常這個(gè)時(shí)候只會(huì)做一些 Query Element + DOM manipulation。
?
DestroyHooks?(OnDestroy)
Dynamic Component 章節(jié)會(huì)教。
?
Example
以前寫的一些例子?Github – angular-blog-component-lifecycle-hooks。
結(jié)構(gòu)
<!-- app.html --> <app-child> <app-transclude-to-child></app-transclude-to-child> </app-child> <!-- child.html --> <app-inside-child></app-inside-child> <ng-content></ng-content> <!-- inside-child.html --> <p>inside-child works!</p> <!-- transclude-to-child.html --> <app-inside-transclude-to-child></app-inside-transclude-to-child> <!-- inside-transclude-to-child.html --> <p>inside-transclude-to-child works!</p>
結(jié)果
?
AfterRenderHooks (afterNextRender, afterRender)
Angular 在 v16.2 推出了新的 AfterRenderHooks,目前 (v17 版本) 這 2 個(gè) Hooks 任處于?Developer Preview。
不過(guò),依據(jù)目前的線索,這或許是未來(lái) Angular 的 Lifecycle Hooks 方向哦。大家還是趁早多了解一下。
afterRender 函數(shù)
export class AppComponent { constructor() { afterRender(() => { console.log('Hello World'); }); } }
AfterRenderHooks 的使用方式和其它 Lifecycle Hooks 截然不同。
它是通過(guò) afterRender 函數(shù)來(lái) register Hooks 的。
這個(gè) afterRender 函數(shù)依賴 Injector,所以必須在 injection context (e.g. constructor) 內(nèi)才可以使用。
afterRender 源碼逛一逛
我們直接看源碼了解細(xì)節(jié)唄。
三大重點(diǎn):
-
afterRender 依賴 Injector
-
afterRender 只在 browser 執(zhí)行,Server-side Render (SSR) 是不執(zhí)行的。
-
afterRender 可以被取消
以上三個(gè)概念,其它 Lifecycle Hooks 都沒有。
afterRender 會(huì)把 callback 存放到一個(gè)全局變量里,等 Lifecycle 到指定時(shí)刻,所有 callback 會(huì)被拿出來(lái)調(diào)用。簡(jiǎn)單說(shuō)就是一個(gè)典型的觀察者模式。
afterNextRender
afterNextRender 和 afterRender 的區(qū)別類似于 AfterViewInit 和 AfterViewChecked
afterNextRender 只會(huì)執(zhí)行一次。
AfterRenderHook 什么時(shí)候執(zhí)行?
我們先來(lái)溫習(xí)一下 Change Detection 機(jī)制。
ApplicationRef.tick > ViewRef.detectChange > refreshVIew > 遞歸?refreshVIew
PreOrderHooks、PostOrderHooks 都發(fā)生在 refreshView 內(nèi)。
而 AfterRenderHooks 則是在?detectChange 的結(jié)尾,也就是所有 refreshView 之后。
AfterRenderHook 的執(zhí)行順序
First in first out
Hooks 的執(zhí)行順序是 first in first out,先 register 的就先執(zhí)行。
register 發(fā)生在 construtor,所以 App?AfterRenderHooks 會(huì)先于 Child AfterRenderHooks。
這一點(diǎn)和 ViewHooks 是不同的哦,ViewHooks 是從底層到上層,AfterRenderHooks 是上層到底層。
AfterRenderPhase
除了 first in first out 概念,AfterRenderHooks 還分 phrase (階段)。
有 4 個(gè) phrase。
phrase 執(zhí)行的順序是?EarlyRead >?Write >?MixedReadWrite >?Read。
綜合 first in first out 和 phrase 概念,最終的執(zhí)行順序是這樣。
-
先把 phrase: EarlyRead 所有 Hooks 按 register first in first out 執(zhí)行一遍
-
再把 phrase: Write?所有 Hooks 按 register?first in first out 執(zhí)行一遍
-
再把 phrase: MixedReadWrite? 所有 Hooks 按 register?first in first out 執(zhí)行一遍
-
最后是把 phrase: Read 所有 Hooks 按 register?first in first out 執(zhí)行一遍
Nested Hooks
下面這個(gè)叫 Nested Hooks
最好不要搞這么繞...
我們這樣來(lái)理解啊,
假設(shè)一開始有 100 個(gè)?AfterRenderHooks,在 refreshView 執(zhí)行完之后,開始 foreach 100 個(gè)?hooks,
依據(jù) phrase 和 first in first out 順序。執(zhí)行到一半,比如第 50 個(gè)出現(xiàn)了 nested hook,此時(shí)會(huì)把這個(gè) nested hook 先 hold 著,一直到 100 個(gè) hooks 執(zhí)行完。
假設(shè),一共 hold 了 10 個(gè) nested hooks,那這個(gè)時(shí)候才 register 這 10 個(gè) hooks,總數(shù)變成 110 個(gè) hooks。
接著就等下一輪?detectChange 了。(重點(diǎn):這一輪只執(zhí)行 100 hooks,10 nested hooks 只是 register 而已沒有執(zhí)行,等下一輪才執(zhí)行 110 hooks)
AfterRenderCallbackHandlerImpl 源碼
關(guān)于 First in first out,Phrase,Nested Hooks 的相關(guān)源碼在 after_render_hooks.ts
class?AfterRenderCallbackHandlerImpl
Nested Hooks 自動(dòng)執(zhí)行?
上面源碼顯示,Nested Hooks 會(huì)在下一輪 detectChange 才被執(zhí)行,但如果我們做測(cè)試的話,會(huì)發(fā)現(xiàn)它視乎是在同一輪 detectChange 執(zhí)行的。
其實(shí)這是我們的錯(cuò)覺,Angular 調(diào)用 tick 比我們想象中的頻密。
所以它確實(shí)是下一輪 detectChange 才執(zhí)行的。
AfterRenderHooks vs ViewHooks
寫法上的區(qū)別
PreOrderHooks 和 PostOrderHooks 的寫法偏向面向?qū)ο?,一個(gè) interface 配一個(gè)對(duì)象方法。
AfterRenderHooks 則有點(diǎn)函數(shù)式的味道,沒有 interface,不需要對(duì)象方法,直接調(diào)用一個(gè)全局函數(shù),這個(gè)和 inject 函數(shù)就很像。Angular 目前的方向是減少面向?qū)ο螅黾雍瘮?shù)式,棄 decorator。
未來(lái) Signal-based Component 可能會(huì)統(tǒng)一使用?AfterRenderHooks 的寫法。相關(guān)參考:Github –?[Complete] Sub-RFC 3: Signal-based Components
功能上的區(qū)別
AfterRenderHooks 依賴 Injector。
AfterRenderHooks 只在 browser 會(huì)執(zhí)行,Server-side Render (SSR) 不執(zhí)行。
ViewHooks 的執(zhí)行順序是依據(jù)組件,從內(nèi)到外或者從底層到上層,一遍完。
AfterRenderHooks 的執(zhí)行順序分 4 個(gè) phrase,所以會(huì)跑 4 輪,每一輪依據(jù) register 順序 first in first out 來(lái)執(zhí)行。
所以?AfterRenderHooks 其實(shí)比?ViewHooks 復(fù)雜和靈活。
用哪個(gè)?
舊代碼可以不必急改,但新代碼推薦使用新的方式。我目前是沒有看到有什么是?ViewHooks 能做但?AfterRenderHooks 做不了的,所以敢敢用唄。
?
目錄
上一篇?Angular 17+ 高級(jí)教程 – Component 組件 の Dependency Injection & NodeInjector
下一篇?Angular 17+ 高級(jí)教程 – Component 組件 の Query Elements
想查看目錄,請(qǐng)移步?Angular 17+ 高級(jí)教程 – 目錄
?
?
?
?
?
TODO,下面是以前寫的稿,過(guò)陣子就可以洗掉了。
?
前言
我們?cè)?這篇 和?這篇 中已經(jīng)學(xué)習(xí)了幾個(gè)基本的 Lifecycle Hooks. 分別是
constructor
OnInit
AfterContentInit
AfterViewInit
OnDestroy
OnChanges
這篇我們會(huì)把其余的 Lifecycle Hooks 都學(xué)完.
?
Init Group and Changes Group
Angular 的 Lifecycle 可以分為兩組.
第一組有?constructor, OnInit, AfterContentInit, AfterViewInit, OnDestroy
第二組有 OnChanges, DoCheck, AfterContentChecked, AfterViewChecked
在 first time render 時(shí), 上面兩組都會(huì)跑. 但絕大部分情況下我們關(guān)心第一組就可以了.
而在 event 發(fā)生后, 我們更多的是會(huì)用到第二組.
所以我喜歡把它們分開兩組看待.
?
Init Group Lifecycle Hooks (組件內(nèi)視角)
在一個(gè)組件內(nèi)部觀察的話, Lifecycle Hooks 的順序是這樣的
constructor > OnInit > AfterContentInit > AfterViewInit > OnDestroy
下面我講一下各個(gè) hook 的特點(diǎn)
constructor?
1. 這個(gè)階段 @Input 還沒有被賦值, 都是 undefined.?
2. 這個(gè)階段 inject parent 已經(jīng)拿到組件實(shí)例了, 但這個(gè)實(shí)例的 @Input 也是 undefined.?
3. 這個(gè)階段 query child 是連組件實(shí)例都沒有的. 空空如也
4. 這個(gè)階段, 組件 template 還沒有 append 到 document
OnInit
1. 這個(gè)階段 @Input 已經(jīng)有值了.
2. 通常我們會(huì)在這個(gè)階段去 ajax 什么的, 大部分代碼都會(huì)寫在這個(gè)階段里.
3. 如果 @ViewChild / @ContentChild 配置 option static : true, 那么這個(gè)階段已經(jīng)可以拿到組件實(shí)例了, 但是這個(gè)組件是還沒有 OnInit 的 (它的 @Input 都是 undefined)
4. 這個(gè)階段組件 template 已經(jīng) append 到 document 了, 但是涉及 binding 的部分都沒有 render 好 (empty)
AfterContentInit
1. 這個(gè)階段 @ContentChild 已經(jīng)可以拿到組件實(shí)例了, 而且這個(gè)組件已經(jīng) OnInit 好了 (但還沒有 AfterViewInit 哦)
AfterViewInit
1. 這個(gè)階段組件 template binding 的部分都 render 好了.
2. 通常這個(gè)階段我們可以去 read DOM dimension, 比如 window.getComputedStyle 之類的
3. 這個(gè)階段我們不應(yīng)該再去修改 view model 了, 如果要修改那樣配上?requestAnimationFrame, 讓 Angular 進(jìn)入下一個(gè)渲染周期 (這個(gè)是 Change Detection 概念, 這里不過(guò)多展開)
OnDestroy
1. 這個(gè)階段 DOM 已經(jīng)被移除了.
2. 通常我們?cè)谶@個(gè)階段釋放資源, 比如 RxJS unsubscribe?等等.
?
Init Group Lifecycle Hooks (組件外視角)
上一 part 我們是站在一個(gè)組件內(nèi)的視角去看 lifecycle hooks. 現(xiàn)在我們從外部看多個(gè)組件它們 lifecycle hooks 的順序是怎樣的.
首先我們有 5 個(gè)組件
App,?Child,?InsideChild,?TranscludeToChild,?InsideTranscludeToChild
all html
<!-- app.html --> <app-child> <app-transclude-to-child></app-transclude-to-child> </app-child> <!-- child.html --> <app-inside-child></app-inside-child> <ng-content></ng-content> <!-- inside-child.html --> <p>inside-child works!</p> <!-- transclude-to-child.html --> <app-inside-transclude-to-child></app-inside-transclude-to-child> <!-- inside-transclude-to-child.html --> <p>inside-transclude-to-child works!</p>
source 在這里 Github – repository
先了解組件結(jié)構(gòu)
app > child > inside child 這 3 個(gè)就是一層一層進(jìn),?
transclude-to-child 最特別, app.html 把 transclude-to-child 組件 transclude 到 child 組件.
最后 transclude-to-child > inside-transclude-to-child 就是進(jìn)一層.
constructor, OnInit, AfterContentInit, AfterViewInit 的順序.
constructor 環(huán)節(jié)
第一個(gè)環(huán)節(jié)是 constructor. Angular 會(huì)把所有組件都實(shí)例化出來(lái)先.
1. app constructor
然后進(jìn)入 app.html
<app-child> <app-transclude-to-child></app-transclude-to-child> </app-child>
接著
2. child constructor
3. transclude to child constructor
接著進(jìn)入 child.html
<p>child works!</p> <app-inside-child></app-inside-child> <ng-content></ng-content>
4. inside child constructor
進(jìn)入 inside-child.html
<p>inside-child works!</p>
這里沒有組件需要實(shí)例化了. 返回最外面 app,html
<app-child> <app-transclude-to-child></app-transclude-to-child> </app-child>
進(jìn)入 transclude-to-child.html
<p>transclude-to-child works!</p> <app-inside-transclude-to-child></app-inside-transclude-to-child>
5. inside transclude to child constructor
進(jìn)入?inside-transclude-to-child.html
<p>inside-transclude-to-child works!</p>
沒有組件需要實(shí)例化了.?
至此 constructor 環(huán)境結(jié)束. 以下是組件 constructor 的 console
OnInit > AfterContentInit > AfterViewInit 環(huán)節(jié)
和 constructor 不同, Angular 不會(huì)先把所有組件 OnInit 一遍才 AfterContentInit.?OnInit?和?AfterContentInit?是前腳后腳一起的,?看下面例子理解.
1. app init
<body> <app-root></app-root> </body>
由于 app-root 沒有任何的 transclude, 所以 app 組件 AfterContentInit 緊跟著 OnInit 后就觸發(fā)
2. app after content init
進(jìn)入 app.html
<app-child> <app-transclude-to-child></app-transclude-to-child> </app-child>
3. child init
由于 child 有 transclude 所以它的?AfterContentInit 不會(huì)馬上觸發(fā).
4. transclude to child init
transclude to child 沒有 transclude 所以?AfterContentInit 馬上觸發(fā)
5. transclude to child after content init
此時(shí) child 的 transclude 完成了, 所以到它的 after content init?
6. child after content init
進(jìn)入 child.html
<p>child works!</p> <app-inside-child></app-inside-child> <ng-content></ng-content>
7. inside child init
8. inside child after content init
進(jìn)入 inside-child.html
<p>inside-child works!</p>
沒有組件了, 所以開始 render view, 并且觸發(fā) AfterViewInit
9. inside child after view init
到目前為止的 console
回到 child.html
<p>child works!</p> <app-inside-child></app-inside-child> <ng-content></ng-content>
before render child component, 要先處理好 ng-content
?
這個(gè) ng-content 內(nèi)容是 transclude-to-child, 它已經(jīng) after content init 了.
進(jìn)入 transclude-to-child.html
<p>transclude-to-child works!</p> <app-inside-transclude-to-child></app-inside-transclude-to-child>
10. inside transclude to child init?
11. inside transclude to child after content init
進(jìn)入 inside-transclude-to-child.html
<p>inside-transclude-to-child works!</p>
沒組件了, render view
12. inside transclude to child after view init
回到?transclude-to-child.html
<p>transclude-to-child works!</p> <app-inside-transclude-to-child></app-inside-transclude-to-child>
沒有組件了, render view
13. transclude to child after view init
回到 child.html
<p>child works!</p> <app-inside-child></app-inside-child> <ng-content></ng-content>
ng-content 也完成了, 現(xiàn)在 render view
14. child after view init
回到 app.html
<app-child> <app-transclude-to-child></app-transclude-to-child> </app-child>
15. app after view init?
最后的 console
?
Changes Group Lifecycle Hooks
我建議大家先學(xué) Change Detection 在回來(lái)看這個(gè)部分.?
雖然 Changes Group Lifecycle Hooks 在 first time render 也會(huì)觸發(fā), 但很少會(huì)要用到,?
所以這里我 focus 的是后續(xù) event 觸發(fā)的 lifecycle.
DoCheck
DoCheck 發(fā)生在 parent 組件 detectChanges 之后.
比如 ApplicationRef.tick 會(huì)導(dǎo)致 AppComponent DoCheck 觸發(fā).?
如果 AppComponent 也被 detectChanges, 那么其每一個(gè)子組件都會(huì)進(jìn)行 DoCheck, 以此類推.
通常我們會(huì)利用這個(gè) DoCheck 判斷這個(gè)組件需不需要 detectChanges, 如果需要那我們就 markForCheck 它, 讓這個(gè) detectChanges 機(jī)制從上到下持續(xù)執(zhí)行.
通常我們不會(huì)在這個(gè)階段去修改 view model, 當(dāng)然你要改也是可以的. 它還沒有到渲染期.
OnChanges
1. 每當(dāng) @Input 改變, 它就會(huì)觸發(fā), 包括 first time render (input from undefined to value) 也會(huì).
2. 這個(gè)階段我們?nèi)稳豢梢匀バ薷?view model.
AfterContentChecked
當(dāng) transclude 的內(nèi)容渲染完成后觸發(fā).
如果我們組件內(nèi)依賴 transclude 內(nèi)容做一些事情. 那就可以在這個(gè)期間去 update 自生的 view model.?
這個(gè)期間可以修改當(dāng)前組件的 view model, 但是不能修改 transclude 進(jìn)來(lái)組件的 view model 哦, 因?yàn)?transclude 的部分已經(jīng)渲染完成了.
AfterViewChecked
顧名思義, 就是當(dāng)前組件渲染完畢后觸發(fā).
通常我們會(huì)在這個(gè)期間去做一些 DOM manipulation (比如獲取 div 寬度/高度, 做一些設(shè)計(jì)).
這時(shí)不可以去修改 view model 了. 如果想修改, 那就需要用 window.requestAnimationFrame 讓它觸發(fā)下一次循環(huán)了. (通常不會(huì)有這種需求啦)文章來(lái)源:http://www.zghlxwxcb.cn/news/detail-837831.html
?
到了這里,關(guān)于Angular 17+ 高級(jí)教程 – Component 組件 の 生命周期鉤子 (Lifecycle Hooks)的文章就介紹完了。如果您還想了解更多內(nèi)容,請(qǐng)?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章,希望大家以后多多支持TOY模板網(wǎng)!