Slide 1
Slide 1 text
ErrorBoundaryとSuspense
導入検討
2024/05/21 FE情報共有会
北嶋初音
Slide 2
Slide 2 text
ErrorBoundaryと
コンポーネントツリー内で発生するJavaScriptランタイムエラーをキャッチし、ア
プリケーション 一部がクラッシュする を防ぐため も 。最終防衛線的なイ
メージ。
function App() {
return (
// Hoge内でエラーが発生したら ErrorBoundaryで定義したフォールバック UIが表示される
);
}
Slide 3
Slide 3 text
Suspenseと
非同期データ 読み込み中にフォールバックUIを表示するため コンポーネン
ト。例え 、データが読み込まれるまで 間にローディングUIを表示するために
使用される。
function App() {
return (
// Hoge内で非同期処理が発生したら Loadingが表示される
Loading...}>
);
}
Slide 4
Slide 4 text
やりたかったこと
● 想定外エラー → すべてErrorBoundaryに任せる
● loading処理 → すべてSuspenseに任せる
function App() {
return (
Loading...}>
);
}
Slide 5
Slide 5 text
これでハッピー！
Slide 6
Slide 6 text
これでハッピー！
になれる ずだった。。
Slide 7
Slide 7 text
ErrorBoundaryで エラーハンドリング
● API通信（axios）側でも「こ パターン 場合 ErrorBoundary相当 も を
表示させたいよ 」的な話が出てきてしまった
○ そこでErrorBoundaryを使うために 、わざわざthrow errorする必要があったりと実装が複
雑になってしまう
● そもそもErrorBoundary 共通エラーハンドリングなど ために利用すべき
で ない、最終防衛線として使う が正しい で使い方がズレてきてしまう
● それであれ 、利用するべきでないという結論に至った
Slide 8
Slide 8 text
Suspenseで ローディング表示
● エラーハンドリングと同様にこちらも個別管理 方が向いているなという結
論
● 例え 、複数 APIを同時に叩く画面で「部分的に取得済み 時 一部
み先に表示したいよ 」といった要求に 答えられなくなる
● 柔軟な対応ができなくなる未来が見えてしまった
Slide 9
Slide 9 text
導入見送り
Slide 10
Slide 10 text
まとめ
● シンプルに設計できる場合に ErrorBoundaryとSuspenseを使っても良さそ
う
● ただし機能要求が複雑になりそうな場合、柔軟性を考えると個別対応する
が無難
● ErrorBoundaryを使うために、、 ように手段と目的が逆転してしまった
少し反省
Slide 11
Slide 11 text
皆さん 商材で 使ってますか？