Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Sign up for free
Menu
Search
Features
All features
Private URLs
Password Protection
Custom URLS
Scheduled publishing
Remove Branding
Restrict embedding
Deck Collections
Notes
Features
All features
Private URLs
Password Protection
Custom URLS
Scheduled publishing
Remove Branding
Restrict embedding
Deck Collections
Notes
Explore
Featured decks
Featured speakers
Programming
Technology
Storyboards
Explore
Featured decks
Featured speakers
Programming
Technology
Storyboards
Pricing
Search
Sign in
Sign up for free
Deep dive into component / classi-angular-night...
Search
Sponsored
·
SiteGround - Reliable hosting with speed, security, and support you can count on.
→
Wataru KASAHARA
June 13, 2019
Programming
2.5k
0
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
Deep dive into component / classi-angular-night-number-3
Wataru KASAHARA
June 13, 2019
More Decks by Wataru KASAHARA
See All by Wataru KASAHARA
NgRx component と component-store について / mini-ng-japan-2020
kasaharu
0
1k
Classi リプレイスプロジェクト フロントエンドアーキテクチャ変遷 / Classi Angular Night #4
kasaharu
3
2k
Angular Way をまっすぐ歩くために / classi-angular-night-number-2
kasaharu
1
2.3k
リプレイスプロジェクトで考えるフロントエンド開発 / Classi Angular Night #1
kasaharu
3
2.7k
React 初心者が初級者になるまで / react-sakana
kasaharu
0
67
Other Decks in Programming
See All in Programming
protojson における文字化けの扱い
kazuki1023
0
150
느린 네트워크와 저사양 디바이스 사용자를 위한 웹뷰 로딩 시간 개선기
kmkim
1
210
Seven New Principles of Software Engineering
yegor256
0
470
TS 7.0 で baseUrl が使えなくなった今、パスエイリアスをどうするか
bicstone
2
560
Modernizing iOS Apps
seyfoyun
0
150
Railsのためのパスキー実践入門 〜マルチテナントSaaSでの意思決定〜
utakaha
4
3.5k
地方こそサーバーレス — 10年続けた、顔が見えるチームで確かな基盤を / Serverless Matters Most in Regional Areas — 10 Years of Building Reliable Foundations with Close-Knit Teams
seike460
PRO
1
270
當我們開始不讀 Code - AI Agent 時代,Code Review 與 Clean Code 還剩下什麼?
jame2408
1
360
動画プレイヤーはなぜカクつくのか 〜Flutterのレンダリングとネイティブの境界を解剖する〜
naruogram
0
330
LLM 101
dalinaum
0
470
SODA - FACT BOOK(EN)
sodainc
1
220
3回つくってわかった、 定期実行ジョブ基盤の本質情報
takai
4
3.7k
Featured
See All Featured
HU Berlin: Industrial-Strength Natural Language Processing with spaCy and Prodigy
inesmontani
PRO
0
800
[SF Ruby Conf 2025] Rails X
palkan
3
1.5k
The browser strikes back
jonoalderson
0
1.9k
AI Search: Where Are We & What Can We Do About It?
aleyda
0
8.2k
Have SEOs Ruined the Internet? - User Awareness of SEO in 2025
akashhashmi
0
550
How To Stay Up To Date on Web Technology
chriscoyier
790
250k
Optimizing for Happiness
mojombo
378
71k
Six Lessons from altMBA
skipperchong
29
4.6k
Marketing to machines
jonoalderson
1
6k
Reality Check: Gamification 10 Years Later
codingconduct
0
2.4k
The Limits of Empathy - UXLibs8
cassininazir
2
770
What the history of the web can teach us about the future of AI
inesmontani
PRO
3
790
Transcript
Deep dive into component 2019/06/13 Classi Angular Night #3
Classi 株式会社 笠原渉
• 笠原 渉 (かさはら わたる) • Classi 株式会社 •
フロントエンドエンジニア • Angular 日本ユーザー会 staff About me @kasaharu
Deep dive into component Component
Deep dive into component Component 画面の表示に欠かせない マークアップをするところ 親から子へ プロパティ受け渡す 受け取ったプロパティを
表示用に加工
マークアップするだけなら単純だが… - 条件によって生成 or 破棄 - Input が与えられたら画面更新 -
イベントが発火しても画面更新 … などなど Deep dive into component
マークアップするだけなら単純だが… - 条件によって生成 or 破棄 - Input が与えられたら画面更新 -
イベントが発火しても画面更新 … などなど Deep dive into component コンポーネントの ライフサイクル コンポーネントの変更検知
- コンポーネントのライフサイクルについて - どうやって変更検知しているか - パフォーマンスに優しい書き方 目次
Component Lifecycle
Component lifecycle ライフサイクルメソッド知ってますか?
- ngOnInit : generate component すると書いてあるアレ - ngOnChanges :
入力値が変わったときの処理を書くアレ - ngOnDestroy : Observable の購読完了処理をしたりするアレ Component lifecycle
Component lifecycle lifecycle method ngOnChanges ngOnInit ngDoCheck ngAfterContentInit ngAfterContentChecked ngAfterViewInit
ngAfterViewChecked ngOnDestroy - 8 つのメソッドがある - この順番で実行される
Component lifecycle lifecycle method ngOnChanges ngOnInit ngDoCheck ngAfterContentInit ngAfterContentChecked ngAfterViewInit
ngAfterViewChecked ngOnDestroy - 初回は ngOnInit より先に呼ばれる - Input プロパティが渡されていないと呼ばれない - SimpleChanges 型のオブジェクトを引数で受け取 れ、今のプロパティと前のプロパティがわかる - firstChange フラグで初回かどうかもわかる 入力値を使って処理をする場所
Component lifecycle lifecycle method ngOnChanges ngOnInit ngDoCheck ngAfterContentInit ngAfterContentChecked ngAfterViewInit
ngAfterViewChecked ngOnDestroy - コンポーネント生成後に呼ばれる - Input プロパティに値がセットされた後に呼ばれる ことが保証されている - どんなコンポーネントも 1 回は呼ばれる 初期化処理をする場所
Component lifecycle lifecycle method ngOnChanges ngOnInit ngDoCheck ngAfterContentInit ngAfterContentChecked ngAfterViewInit
ngAfterViewChecked ngOnDestroy - 変更検知のたびに呼ばれる - 変更検知については後述
Component lifecycle lifecycle method ngOnChanges ngOnInit ngDoCheck ngAfterContentInit ngAfterContentChecked ngAfterViewInit
ngAfterViewChecked ngOnDestroy - コンポーネント内の外部のビューに値が反映され た後に呼び出される - 呼び出されるのは最初の ngDoCheck の後のみ
Component lifecycle lifecycle method ngOnChanges ngOnInit ngDoCheck ngAfterContentInit ngAfterContentChecked ngAfterViewInit
ngAfterViewChecked ngOnDestroy - コンポーネント内の外部のビューに値が変更され た後に呼び出される - 初回は ngAfterContentInit の後に、その後は ngDoCheck の後に呼ばれる
Component lifecycle lifecycle method ngOnChanges ngOnInit ngDoCheck ngAfterContentInit ngAfterContentChecked ngAfterViewInit
ngAfterViewChecked ngOnDestroy - コンポーネント内のビューの値が反映されたあと に呼ばれる - ngAfterContentChecked の後に呼ばれる
Component lifecycle lifecycle method ngOnChanges ngOnInit ngDoCheck ngAfterContentInit ngAfterContentChecked ngAfterViewInit
ngAfterViewChecked ngOnDestroy - コンポーネント内のビューの値が変更されたあと に呼ばれる - 初回は ngAfterViewInit の後に、その後は ngAfterContentChecked の後に呼ばれる
Component lifecycle lifecycle method ngOnChanges ngOnInit ngDoCheck ngAfterContentInit ngAfterContentChecked ngAfterViewInit
ngAfterViewChecked ngOnDestroy - コンポーネントが破棄されるときに呼ばれる - Observable の購読解除などをやる場所
Component lifecycle lifecycle method ngOnChanges ngOnInit ngDoCheck ngAfterContentInit ngAfterContentChecked ngAfterViewInit
ngAfterViewChecked ngOnDestroy - ここで再度 ngDoCheck
Component lifecycle lifecycle method ngOnChanges ngOnInit ngDoCheck ngAfterContentInit ngAfterContentChecked ngAfterViewInit
ngAfterViewChecked ngOnDestroy 変更検知のたびに呼ばれる → ngAfterContentChecked が呼ばれる → ngAfterViewChecked が呼ばれる → コストが高い できればここで処理をしない
変更検知
- 変更検知とは? - JS 側で発生したイベントを Angular に伝える仕組み -
誰が伝えているか? - Zone.js - 何を検知する? - XHRによる非同期通信、タイマー処理、クリックイベント など 変更検知
変更検知 HomeComponent Child100Component Child300Component Child200Component Child310 Child320 Child210
変更検知 HomeComponent Child100Component Child300Component Child200Component Child310 Child320 Child210 Click 検知
変更検知 HomeComponent Child100Component Child300Component Child200Component Child310 Child320 Child210 ngDoCheck ngAfterContentChecked
変更検知 HomeComponent Child100Component Child300Component Child200Component Child310 Child320 Child210 ngDoCheck ngAfterContentChecked
変更検知 HomeComponent Child100Component Child300Component Child200Component Child310 Child320 Child210 ngDoCheck ngAfterContentChecked
ngAfterViewChecked
変更検知 HomeComponent Child100Component Child300Component Child200Component Child310 Child320 Child210 ngAfterViewChecked
変更検知 HomeComponent Child100Component Child300Component Child200Component Child310 Child320 Child210 ngAfterViewChecked
変更検知 どこかのコンポーネントで 変更検知のトリガーとなるイベントが発生 最上位のコンポーネントから順に 全てのコンポーネントで変更検知が走る
- フレームレートが 60fps あるとスムーズなアニメーション - つまり 1 フレームあたり 16msec しか使えない
- ref. RAIL モデル - 変更検知のたびに全てのコンポーネントを精査するとパフォーマンスに 悪い 変更検知
- フレームレートが 60fps あるとスムーズなアニメーション - つまり 1 フレームあたり 16msec しか使えない
- ref. RAIL モデル - 変更検知のたびに全てのコンポーネントを精査するとパフォーマンスに 悪い 変更検知 ChangeDetectionStrategy
- ChangeDetectionStrategy - 変更検知についての戦略を決める - Default - CheckAlways
strategy : 毎回チェックする - OnPush - CheckOnce strategy : 1 度だけチェックする → Input が変わらない限りコンポーネントの状態が変化しないと判断 変更検知
変更検知 HomeComponent Child100Component Child300Component Child200Component Child310 Child320 Child210
- OnPush 実際にどれくらい効果があるんですか? 変更検知
- OnPush 実際にどれくらい効果があるんですか? - angular/platform-browser の enableDebugTools を使うと計測できる -
ref. Developer Tools for Angular 変更検知
- enableDevTools を設定すると Chrome DevTools で計測できる - ng.profiler.timeChangeDetection()
- 簡単な構成でも 13msec -> 2msec くらいになる 変更検知
パフォーマンスを気にしたコーディング
- OnPush を使うためには Input プロパティ以外でコンポーネントの状態 が変わらないように実装する必要がある - Presentational component
は基本的に Input プロパティが変更された 場合のみ変更処理を必要とし、その他では変わらないようにしておくと 良い - Input プロパティが多くなると ngOnChanges の処理が膨らむ可能性が あるので getter などを使って適切に処理をわける パフォーマンスを意識したコーディング
- CheckOnce にして変更検知の回数を減らす - generate コマンドのオプションでも設定可能 - $ ng g
c home -c OnPush ChangeDetectionStrategy
- Input が変わる度に更新する値がある場合 ngOnChanges を使う - Input プロパティが増えると条件分岐が増えてくる -
→ getter を使うとよい ngOnChanges
- Input ごとに getter を用意することで処理が複雑にならない - template でメソッドが呼ばれる → AfterViewChecked
のたびに処理される - getter に重い処理(配列操作など)があるとパフォーマンスが悪くなる - → setter を使うとよい getter
- 該当の Input が変更されると setter が呼ばれる - template からは変更検知のたびに getter
が呼ばれる - 処理自体は setter にあり getter は処理済みの値を返すのみなので影響は少ない setter
- ライフサイクルメソッドのメリット・デメリットを知る - ChangeDetectionStrategy.OnPush でパフォーマンス改善 - getter, setter
で実装の複雑さを減らす - enableDebugTools で計測してみる まとめ
We are Hiring! Classiでは一緒に働く仲間を募集しています 詳細はWantedlyページにて https://www.wantedly.com/companies/classi/projects