async_awaitとAbortControllerでReact通信を堅牢にする

えーと、今回共有してもらったソースなんですけど、リアクトでボタンを押した瞬間に画面がこう数秒固まっちゃうっていう問題から始まってますよね。 はい。これ裏で通信が終わるのを、なんていうかブラウザが権限に 全部の作業を止めて待っちゃってる。いわゆる同期処理が原因ということなんですよね。 まさに。レストランで注文したあと、料理が出てくるまでずっとレジの前で立ち続けてるのと同じ状態ですね。 あー、なるほど。そこで重要になるのが非同期処理なんです。呼び出しベルをもらって席で待てるみたいな。 そうそう。その呼び出しベルの仕組み、面白いですよね。 今回はそのベルを持って席で待つ方法を、JavaScriptのフェッチAPIと 魔法の呪文なんて言われてるアシンクアウェイトでどう実現するのか深掘りしていきましょうか。 いいですね、ぜひお願いします。ええ、じゃあまずその魔法の正体からなんですけど、 関数にアシンクってつけるのは、この関数の中では時間の掛かる処理を待つことがありますよっていう宣言みたいなものなんです。 なるほど、宣言。そしてその中で使うのがアウェイトです。時間の掛かるフェッチの前にアウェイトを置くと、 この処理が終わるまで待って、でもブラウザ全体の動きは止めないでねという指示になるんです。 本当に呼び出しベルが鳴るのを待ってる感覚そのものですね。その通りです。 で、ここがすごく大事なポイントで、もしアウェイトを使わなかったら、サーバーからデータが届く前に次の処理に進んじゃうんです。 あー。結果として画面にデータがありませんって表示しようとして、いわゆるアンディファインドエラーが起きると。 なるほど。アウェイトで待つことでデータ取得が確実になると。でもちょっと待ってください。 待った結果がサーバーが見つかりませんとかだったら、結局困っちゃいますよね。その場合はどうなるんですか？ あ、良い質問ですね。そこで必要になるのがトライキャッチ文です。トライキャッチ。 ええ。これはもうアシンクアウェイトを使う上での作法といってもいいかもしれません。 成功するか分からないフェッチをトライのブロックで囲んで、もし通信失敗とかサーバーエラーが起きれば、 キャッチのブロックがそれを捕まえてくれるんです。アプリがクラッシュするのを防いでくれるわけですね。 そうです。それでそのキャッチの中では、ユーザーさんに通信に失敗しましたみたいなメッセージを見せつつ、 開発者向けにはエラーの詳細を記録しておくというのが一般的ですね。なるほど。 ただ、ここに一つ小さな落とし穴があって。ほう。通信自体は成功しても、 サーバーがページが見つかりませんっていう404エラーを返すことってありますよね。 ありますね。フェッチはこれをエラーと見なさないんですよ。なのでレスポンスドットオーケーという プロパティがトゥルーかどうかを確認する一手間が、より丁寧なエラー処理に繋がります。 深いですね。でも、もう一つ気になるのが、もしユーザーがデータ取得が終わる前に 待ちきれずに別のページに移動しちゃったらどうなるんでしょうか。ええ、非常に重要な点です。 その場合、完了した通信がもう存在しない画面の情報を更新しようとしてしまって、 リアクトだとエラーが発生します。置き去りのリクエストですね。ええ。 それを防ぐのがアボートコントローラーなんです。アボートコントローラー。これ正直、 そこまでやる必要があるのかなって感じる人もいるかもしれないですけど、実際どうなんですか？ 私も若い頃はそう思ってたんですけど、これを忘れてデモ中にアプリがクラッシュした苦い経験がありまして。うわー。 それ以来、エフェクトでフェッチを書くときは、もうお守りのようにアボートコントローラーを入れています。 不要になったリクエストをキャンセルする仕組みで、これがあるかないかでアプリの安定性が全然違うんです。 なるほど。レストランの例えで言うと、急用ができて、すみません、もう行かなきゃいけないんで 注文キャンセルで、て厨房に伝えに行く感じですね。まさにその通りです。 その一言が無駄な調理とか混乱を防ぐわけですからね。なるほど、よく分かりました。 じゃあ整理すると、まずアシンクアウェイトでユーザー体験を止めない。そしてトライキャッチで予期せぬエラーに備える。 最後にアボートコントローラーで後始末まできっちり行う。この3ステップが、 動くだけのコードから本当に信頼性の高いアプリケーションへの分かれ道だってことですね。 まさに、この考え方が快適なウェブ体験の土台になります。さて、今回は一つのリクエストを扱いましたが、 じゃあもしユーザーのプロフィール情報とその人の最新の投稿一覧っていう複数の情報を同時に取得したい場合は どうすればいいでしょうか。ああ、確かに。片方の通信が失敗したとき、もう片方はどう扱うべきか。 この問いがプロミスドットオールとかプロミスドットオールセトルドといった、さらにその先の非同期処理の世界への入り口になるわけです。