エラーハンドリング:Axios Interseptor【React】

初めに

今回は、エラーハンドリングの方法としてAxiosのInterseptorを用いる方法について紹介します。Axios【Interseptor】の基礎的な使い方とReactのコンポーネントとしてAxios【Interseptor】を使用する方法について解説します。

どもども新米フロントエンドエンジニアの龍ちゃんです。エラーハンドリングが直近の議題+ブログの題材になっています。いろいろな方法がありますが「非同期処理(API処理)のエラーハンドリングにはいい選択」という先輩からの助言を頂いたのでブログの題材にできます。

このブログは以下の二点について解説しています。

  • Axios Interseptorの基本的な使い方
  • Axios Interseptorを用いた非同期処理(API処理)エラーハンドリング方法の提案

それではブログの方を進めていきます。

Axios Interseptor

AxiosのInterseptorのざっくりとした理解では、「Axiosを利用して通信する際にrequestとresponseの前後に共通の処理を挟み込むことができる」ものだと考えています。概念的な理解としては以下の図になります。

Axios Interseptorについての説明
Responseでは成功時と失敗時で処理を振り分けることができる

requestとresponseで挟み込む処理では意味が異なってきます。requestでは、送信前のrequestを取得することができます。なので「logの記録」などが主な役割になりそうです。responseでは、APIの通信が成功した場合と失敗した場合で処理を分岐させることができます。失敗の場合では、エラーの内容を取得することができます。なのでrequestと同様に「エラーの記録」も行えます。成功の場合は、特に記録する必要がなければスルーで問題ないと思います。

それでは、AxiosのInterseptorを使用していきましょう。AxiosのInterseptorを使用する場合は以下のコードを参考にしていただければ、requestとresponseの前にコンソールに情報が表示されると思います。

今回のコードではInterseptorの設定以外に以下のコードを使用して初期設定を行っています。

export const axiosClient = axios.create({
  timeout: 1000,
  headers: {
    'Content-Type': 'application/json',
  },
  baseURL: 'https://localhost:4242',
});

こちらのコードでは、Axiosの規格を設定することができます。僕が使用していた規格は、「timeout」・「headers」・「baseURL」です。「timeout」では、Axiosの通信のタイムアウトを設定することができます。「header」では、ヘッダーに情報を設定することができます。認証情報の追加、通信の際に使用するコンテントタイプの設定情報追加などが行えます。「baseURL」ではAPI通信のOrigin部分のURLを記しておくと自動でリライトされます。こちらを設定しておくと、デプロイ先とAPIのURLが異なる場合に楽にアクセスすることができます。

React Axios エラーハンドリング

それでは、React上でエラーハンドリングの形に落とし込んでいきたいと思います。いきなりコード掲載は不親切なので、構築の基本となる部分から順を追って進めていきたいと思います。それでは初めて行きます。

ステータスコード

非同期処理のエラーハンドリングを行うためには、振り分けのためのステータスコードについて知る必要があります。使用する種類としては、以下の図になります。

ステータスコードで分岐させる
200系は成功レスポンス
400系はクライアントエラーレスポンス
500系はサーバーエラーレスポンス

エラーの種類としては、「200系」・「400系」・「500系」とそれぞれあります。それぞれのステータスコードによって意味が異なるため、エラーハンドリングとしてエラーを通知する方法もそれぞれ異なります。「200系」の場合では、成功しているのでエラーハンドリングは必要ありません。「400系」の場合では、クライアントの操作によるエラーの可能性があるのでクライアント側に通知する必要があります。「500系」の場合では、サーバーが落ちている可能性があるのでアプリの使用を止める必要があります。

React Axios Error Handling Component

それでは、AxiosのInterseptorをコンポーネントに落とし込んでエラーハンドリングを行っていきたいと思います。まず、今回の構成における概念について説明していこうと思います。まず、「AxiosErrorHandlingComponent.tsx」というファイルでAxiosのInterSepterを用いてエラー状態を監視します。正常に動作している場合は、「MyPageComponent」を表示し、エラーが発生した場合は「ErrorPage」に画面を差し替えます。

「ErrorPage」の機能としては、リロード機能を実装しています。これはエラーが時間経過で解消する場合に限り効果を発揮します。

エラーハンドリング:Axios Interseptor【React】提案

それでは実際のコードを基に説明していきます。

「useEffect」を内でAxiosのInterseptorを定義しています。今回は「NETWORK ERROR」をキャッチするために条件式を書いています(APIサーバーを作成していないので適当なリンクにアクセスしています)。また、ステータスコードが「500」以上の場合と「NETWORK ERROR」の場合では、「serverError」が「true」になります。「serverError」が出た場合は、エラーページが出力されます。エラーが出ていない場合は、propsで定義しているコンポーネントがそのまま出力されます。

propsで「children」の名前で定義した場合では、以下のように記述することで、コンポーネントで挟んだコンポーネントが渡されます。使い方としては以下のコードを参考にしてください。

一つ注意点があります。「axiosClient」と先ほどのファイルで定義した「axiosオブジェクト」を使用する必要があります。もし「axios」とそのまま呼び出してしまうとうまく動作しません。

今回は「500系」のエラーにしか対応していませんが、「switch文」でエラーコードの分岐を書くことでエラーハンドリングを行うことができます。

コンポーネントの差し替えだけでなく、「Recoil」などを使用して状態管理用の変数を用意してページごとでハンドリングを行う方法なども存在しています。今回は、一番シンプルな形で実装してみました。

終わりに

お疲れ様です。今回の記事は、前回記事「エラーハンドリングと向き合うための準備【React】」で調べたリンクを用いて今回の記事を作成しました。以下がリンクになります。

内容で詰まった部分としては、登録したInterseptorをアンマウント時に解除する手順です。「logの記録」に関しては、APIを構築しているサーバー側で記録する方が多いような気がしています。フロント部分でlogを記録するメリットがあるかどうかは正直わかりません。

今回は、エラーハンドリングに使用しましたがもっと別の利用方法について社内で確認をしていきたいと思います。

次回は、標準のエラーハンドリングについて触れたいと思います。それではまた!

ご覧いただきありがとうございます! この投稿はお役に立ちましたか?

役に立った 役に立たなかった

1人がこの投稿は役に立ったと言っています。

コメントを残す

メールアドレスが公開されることはありません。 が付いている欄は必須項目です