https://zenn.dev/abeshi/articles/486dc6d6185b1b

React Queryを使ってみて、設計に関して考えてみたので書いていきます。

※注意点 今回はReact Queryの使い方や一番の持ち味であるキャッシュに関しては特に深ぼっていきません。 いかに分かりやすく、変化に強い設計ができるかをテーマに進めていきます。

React Queryの使い方

async function fetchUser(userId: number) {
  const response = await fetch(
    `http://localhost:5000/users/${userId}`
  );
  return response.json();
}
const { data, isError, error, isLoading, isFetching } = useQuery(
    'user',
    () => fetchUser(userId)
  );

基本的な使い方はこんな感じです。 getリクエストをする際にuseQueryを使用し、第一引数にkeyを指定し、第二引数にfetch処理をした関数を渡していきます。

従来ようにLoadingなどをstateとして管理しuseEffectで関数を実行しなくても短い処理で書けるので非常に便利です。

しかし、こちらのコードには問題点がたくさんあります。

問題点

まずはエンドポイントをハードコーディングしている点です。 コンポーネント内部にエンドポイントをハードコーディングしていると、エンドポイントが変わった際に、全てのファイルのエンドポイントを変更しなければなりません。

そして二つ目はコンポーネント内部に全ての処理が書かれている点です。 これでは、処理が増えてくると、コンポーネント内のロジックが肥大化し、可読性が失われてしまいます。

そして何より、TypeScriptの持ち味である、型のドキュメント化が全くできていません。 このようにfetch処理が各ファイルに散らばっていると、このアプリケーションにどんなapiがあるのかが、ソースコードをみただけでは全く判断する事ができません。

上記の観点をこれから改善していきます。

ディレクトリ設計

以下のようなディレクトリ設計にしました。

.
├── src
│   ├── apis
│   │   ├── gateways
│   │   ├── hooks
│   │   ├── implements
│   │   ├── requests
│   │   ├── responses

まずapiに関する処理をapisに全てまとめていきます。 第三者がapiの内容を確認する時にみるディレクトリはここだけです。

各ディレクトリの役割は下記です。