環境の切り替え対象

• APIのエンドポイントなどの切り替え
  • react-native-config を使用する
• Release, Debug ビルドでの設定の切り替え、Firebase の設定ファイル (GoogleService-Info.plist)
  • iOS, Android のビルド時の設定変更の機能を使用して、切り替える

react-native-config の導入

$ yarn add react-native-config
$ react-native link react-native-config
$ (cd ios; pod install)

iOSの環境の設定切り替え

• こちら を参考にし、Target のコピー、Scheme 追加
• 6 の pre-action step
  • PROJECT_DIR の .env を書き換えるため、ローカル実行時は ENVFILE=.env.local を使用するなど工夫する
• react-run-ios --scheme "作成したTarget名" で起動する

GoogleService-Info.plist の配置

• 各 Target の名前のディレクトリを作成しその配下に置く
• XCode で GoogleService-Info.plist を選択 -> TargetMembership で読み込む Target を指定する

注意点

• build の Info タブで React のチェックを外さないようにする
  • テスト等、コピー元のTargetにチェックが入っている場合、react-run-ios 時にそちらの app が起動してしまう
• こちら を参考に Podfile の書き換えを行う

Android の環境の設定切り替え

• ProductFlavorの設定をしておく
• こちらを参考に設定
  • 作成した variant 名でを指定 (例: react-run-android --variant=DevDebug)

バージョン/ビルドバージョンの書き換え用のコードの用意

yarn run set:version {次のバージョン番号} {次のビルド番号} のような形で起動

setVersion.js

const fs = require('fs');
const { execSync } = require('child_process');

const version = process.argv[2];
if (!version) {
  throw 'version が指定されていません';
}
const build = process.argv[3];
if (!build) {
  throw 'build が指定されていません';
}
console.log(`build: ${version}`);

// ファイル文字列置換
const versionFiles = [
  {
    name: 'src/constants.js',
    regex: /export const appVersion.*/,
    replace: `export const appVersion = "${version}";`
  },
  {
    name: 'android/app/build.gradle',
    regex: /    versionName .*/,
    replace: `    versionName "${version}"`
  },
  {
    name: 'android/app/src/main/AndroidManifest.xml',
    regex: /    android:versionName=.*/,
    replace: `    android:versionName="${version}">`
  }
];
const buildFiles = [
  {
    name: 'android/app/build.gradle',
    regex: /    versionCode .*/,
    replace: `    versionCode ${build}`
  },
  {
    name: 'android/app/src/main/AndroidManifest.xml',
    regex: /    android:versionCode=.*/,
    replace: `    android:versionCode="${build}"`
  }
];

console.log("\nreplace version");
for (const file of versionFiles) {
  const data = fs.readFileSync(file.name, 'utf8');
  const target = data.match(file.regex);
  console.log(`  file: ${file.name}`);
  console.log(`     ${target}`);
  console.log(`  -> ${file.replace}\n`);
  const replaced = data.replace(file.regex, file.replace);
  fs.writeFileSync(file.name, replaced, 'utf8');
}

console.log("\nreplace build");
for (const file of buildFiles) {
  const data = fs.readFileSync(file.name, 'utf8');
  const target = data.match(file.regex);
  console.log(`  file: ${file.name}`);
  console.log(`     ${target}`);
  console.log(`  -> ${file.replace}\n`);
  const replaced = data.replace(file.regex, file.replace);
  fs.writeFileSync(file.name, replaced, 'utf8');
}

// ios 設定変更
console.log("\nreplace version in xcode\n");
execSync(`cd ios/ && agvtool new-marketing-version ${version}`, {stdio: 'inherit'});
console.log("\nreplace build in xcode\n");
execSync(`cd ios/ && agvtool new-version -all ${build}`, {stdio: 'inherit'});

参考

https://github.com/luggit/react-native-config
https://dev.classmethod.jp/articles/xcode-build-environment-adding-scheme/
https://gist.github.com/jacks205/45b2721bf2a2b912b1c130aef2572820#ios-instructions

Redux ExampleのTodoListをReact Native（expo）に置き換えて解説のToggleTodo編です。
AddTodo編は以下です。
Redux ExampleのTodoListをReact Native（expo）に置き換えて解説AddTodo編

注：僕は掛け出しエンジニアであり、自分の勉強としての投稿という面もあるので、もしミスや勘違い、ベストプラクティスではない、等がありましたら、コメントしていただけると幸いです。

TODOに属性を追加

まずは、todoにcomplete属性を追加してtodoが完了済みなのかactive状態なのかを判定できるようにします。初期値はfalseにしておきます。

reducers/todos.js

const todoReducers = (state = [], action) => {
    switch(action.type){
        case 'ADD_TODO':
            return [
                ...state,
                {
                    id: action.id,
                    text: action.text,
                    completed: false //追加
                }
            ]
        default:
            return state
    }
}

export default todoReducers

Todoのcompleted属性がtrueかfalseによって見た目を変えたいので、TodoListコンポーネントを修正します。

components/TodoList.js

class TodoList extends Component {
  render() {
    return (
      <View>
        <FlatList
          data={this.props.todos}
          renderItem={({ item }) => (
            <View style={styles.todoList}>
              <Text
                style={{　
                 textDecorationLine: item.completed ? "line-through" : "none",
                }}　//追加↑
              >
                {item.text}
              </Text>
            </View>
          )}
          keyExtractor={(item) => item.id.toString()}
        />
      </View>
    );
  }
}

ここで、動作確認のため、reducers/todos.jsのcompleted属性をtrueにしてみましょう。todoに斜線が引かれていると思います。

Actionからcompleted属性を操作する

次に、上記でやったtrue,falseの操作をActionを経由して操作できるようにしましょう。

まずはActionCreatorを作成します。どのtodoに横線を引くかを判別するためにidを取得します。

src/actions/index.js

let nextTodoId = 0
export const addTodo = text => ({
    type: 'ADD_TODO',
    id: nextTodoId++,
    text
})    

//追加
export const toggleTodo = (id) => {
  return {
    type: "TOGGLE_TODO",
    id,
  };
};

reducersも変更します。

reducers/todos.js

const todoReducers = (state = [], action) => {
  switch (action.type) {
    case "ADD_TODO":
      return [
        ...state,
        {
          id: action.id,
          text: action.text,
          completed: true,
        },
      ];
    case "TOGGLE_TODO": //追加
      return state.map((todo) =>
        todo.id === action.id ? { ...todo, completed: !todo.completed } : todo
      );
    default:
      return state;
  }
};

export default todoReducers;

やっていることとしては、stateに保存されている全てのtodoについて、それぞれのidとActionCreatorに渡された、横線を引きたいtodoのidを比べて、一致したらそのtodoのcompleted属性を逆転させるというものです。

ここで、例の如くApp.jsから動作確認をしてみましょう
App.jsに以下を追加してみましょう。

App.js

import { addTodo, toggleTodo } from './actions'

store.dispatch(addTodo('Hello React!'))
store.dispatch(toggleTodo(0))

画面をみてみると斜線が引かれたtodoが追加されているはずです。

Todoをクリックしてcompleted属性を操作できるようにする

それでは、画面上からtodoの完了、未完了の操作ができるようにしましょう。mapDispatchToPropsを作成します。
これはcomponentで(今回で言えばTodoListで)dispatchをpropsとして渡せるものです。

こうすることで、component側ではthis.props.onTodoClick(id)の形で先ほどApp.jsでやったdispatch(toggleTodo(0))みたいなことができるようになります。

containers/VisibleTodoList.js

import { connect } from "react-redux";
import TodoList from "../components/TodoList";
import { toggleTodo } from "../actions"; //追加

const mapStateToProps = (state) => {
  return { todos: state.todoReducers };
};

//追加
const mapDispatchToProps = (dispatch) => {
  return {
    onTodoClick: (id) => {
      dispatch(toggleTodo(id));
    },
  };
};

//追加
const VisibleTodoList = connect(mapStateToProps, mapDispatchToProps)(TodoList);
export default VisibleTodoList;

これでTodoListの方でonTodoClickが使えるようになったので、追加してみましょう。

components/TodoList.js

return (
      <View>
        <FlatList
          data={this.props.todos}
          renderItem={({ item }) => (
            <View style={styles.todoList}>
              <Text
                onPress={() => this.props.onTodoClick(item.id)}
                style={{
                  textDecorationLine: item.completed ? "line-through" : "none",
                }}
              >
                {item.text}
              </Text>
            </View>
          )}
          keyExtractor={(item) => item.id.toString()}
        />
      </View>
    );

これでtodoをクリックすると該当のtodoに斜線が引かれます。

ToggleTodo編は完成です！
お手元のシミュレーターでお試しください。
ここまでのソースコードはGitHubに上げていますのでご参考ください。

次回は表示するTodoをcompleted属性によって切り替える「FilterTodo」機能を実装していきます。

参考

Redux ExampleのTodo Listをはじめからていねいに(2)

概要

・next.jsでは「.env.local」ファイルで環境変数を設定できる。
・クライアント側でも環境変数を設定したいときは接頭語に「NEXT_PUBLIC_」をつける
・開発環境は「.env.development」、本番環境は「.env.production」でそれぞれの環境変数を設定できる

環境変数を設定する（サーバー編）

next.jsでは簡単に環境変数を変更する仕組みがあります。
ルートディレクトリに「.env.local」ファイルを置き、その中で定義した環境変数はアプリの中で使うことができます。

たとえば、開発環境と本番環境で異なるデータベースを使いますよね。そんな時に「.env.local」ファイルに設定すれば環境変数をアプリ内で利用できます。

env.local

DB_HOST=localhost
DB_USER=root
DB_PASSWORD=root

環境変数の使用.js

export async function getServerSideProps(context) {
  console.log(process.env.DB_HOST) //コンソールに「localhost」を出力（サーバー側）
  return {props: {}}
}

環境変数に他の環境変数を設定したい場合

また、「.env.local」で設定した環境変数を別の環境変数で使うには、「$」を使います。
たとえば、ホスト名にポート番号を追加したいときには以下のように定義します。

env.local

PORT=3000
HOST=http://localhost:$PORT

index.js

export async function getServerSideProps(context) {
  console.log(process.env.HOST) //コンソールに「http:localhost:3000」を出力（サーバー側）
  return {props: {}}
}

環境変数を設定する（クライアント編）

先ほどの、「.env.local」で設定した環境変数はnode.jsのみで適用されます。そのため、ブラウザ側で動くプログラムでは使うことができません、
クライアント側でも環境変数を使いたいときにはどうすればいいのでしょうか？

この問題を解決するのが環境変数の接頭語の「NEXT_PUBLIC_」です。環境変数の接頭語に「NEXT_PUBLIC_」をつければ、クライアント側でも使うことができます。
これにより、ブラウザ側、サーバー側どちらでも環境変数を利用できるのです。

env.local

NEXT_PUBLIC_TEST=client-server

index.js

export async function getServerSideProps(context) {
  console.log(process.env.NEXT_PUBLIC_TEST) //コンソールに「client-server」を出力（サーバー側）
  return {props: {}}
}

const index = () => {
  return <p>{process.env.NEXT_PUBLIC_TEST}</p>  //画面に「client-server」を出力（クライアント側)
}

export default index

環境によって読み込むファイルを変更する方法

環境ごとに読み込む環境変数を変更したい場合があります。
たとえば、開発環境では開発用のDBを使うけど、本番環境では本番用のDBを使いたいなど環境ごとにDBを切り替えたい場面などです。

そんな時は環境ごとのenvファイルを用意します。以下の4種類でそれぞれの環境変数を設定できます。
・.env：全環境共通の環境変数
・.env.development：開発環境（next dev）の環境変数
・.env.production：本番環境（next start）の環境変数
・.env.local：デフォルトの環境変数（すべての環境変数を上書き）

これの環境変数の優先順位は以下の通りです。
①.env.local
②.env.development/.env.production
③.env

基本的に、「.env」にデフォルトで全ての環境変数を設定して、「.env.development」、「.env.production」で上書きするのがいいのではないでしょうか？

参考

next.jsの環境変数の設定

はじめに

以下のような考えを満たすような環境を作ってみました。

• フロントエンドの環境でもクリーンアーキテクチャのようなことをしたい
• 非同期処理はモダンなreact-queryで書きたい
• 今まで慣れ親しんだreduxも入れときたい

コードはこちらにあります
https://github.com/pokotyan/clean-architecture-front

利用パッケージ

利用した主なパッケージなどは以下の通りです。

• tsyringe
  diに利用。typediやinversifyでも同じことができると思います。

• Context
  diコンテナーとして利用

• class-transformer、class-validator
  モデルの生成、バリデーションに利用

• @reduxjs/toolkit
  reduxの導入に利用。グローバルなstateの管理をする

• normalizr
  reduxのストアの正規化に利用

• react-query、Suspense、ErrorBoundary
  非同期処理、エラーハンドリングに利用

• react-router@v6
  ルーティングに利用。v6のインストールは現状 @next を指定する必要があります。
  Suspenceをつかった非同期処理を行う場合、v5以前のものでは相性が悪いらしく、v6を利用しました。参考

作ったアプリ

サンプルとして作ったものは、以下のようなダミーのデータを元に一覧ページ、詳細ページが閲覧できるものです。

データ

src/domain/api/blog/get/index.ts

const blogsData = [
  {
    id: 123,
    user: {
      id: 1,
      name: "Tom",
    },
    title: "引越し",
    body: "引越ししました",
    createdAt: dayjs(),
    comments: [
      {
        id: 324,
        body: "どこに？",
        createdAt: dayjs().add(3, "hour"),
        user: {
          id: 2,
          name: "Bob",
        },
      },
      {
        id: 325,
        body: "今度、家いかせて",
        createdAt: dayjs().add(5, "hour"),
        user: {
          id: 3,
          name: "Sam",
        },
      },
    ],
  },
];

一覧ページ

詳細ページ

ディレクトリ構成

ディレクトリ構成はこんな感じです。

├── src
│   ├── App.tsx
│   ├── ErrorBoundary.tsx // エラーハンドリングのためのコンポーネント
│   ├── components
│   │   ├── containers  // データとコンポーネントの受け渡しをする層
│   │   │   ├── BlogDetail.tsx
│   │   │   └── BlogList.tsx
│   │   ├── oraganisms  // propsでもらったデータをただ表示するコンポーネント
│   │   │   ├── BlogDetail.tsx
│   │   │   └── BlogList.tsx
│   │   └── pages       // ページのコンポーネント
│   │       └── Blog.tsx
│   ├── domain
│   │   ├── api          // apiを叩いてデータを取って来る層
│   │   │   ├── blog
│   │   │   └── schema.ts
│   │   ├── di           // diをする層
│   │   │   ├── blog.ts
│   │   │   └── index.ts
│   │   ├── model        // ドメインロジックを詰めるモデル層
│   │   │   └── blog
│   │   ├── repository   // reduxのstore情報を元にしてモデルを返す
│   │   │   ├── blog
│   │   │   └── index.ts
│   │   └── usecase      // ユースケース層
│   │       └── blog
│   ├── features         // reduxのaction、reducer
│   │   └── blog
│   │       ├── action.ts
│   │       └── reducer.ts
│   ├── hooks            // カスタムフック
│   │   ├── useDI.ts
│   │   └── useQueryWithSuspense.ts
│   ├── index.tsx
│   └── store.ts         // reduxのstore生成

ここからは順を追って、それぞれのディレクトリの処理を見ていきます。

apiからのデータ取得、正規化、reduxのストアへの格納

getBlogs関数は、apiからデータを取得してきたていの関数です。モックのデータをPromiseに包んで返します。

取得したデータはreduxのストアに格納します。
reduxのストアにはapiから取得したデータをそのまま格納するのではなく、正規化した値を入れるのがいいとされているのでそのようにしました。参考

正規化した値を入れることで、データのネスト構造が浅く保てるので、reducerで更新処理がわかりやすくなります。
正規化にはnormalizrを利用しました。

src/domain/api/blog/get/index.ts

import { normalize } from "normalizr";
import dayjs from "dayjs";
import {
  NormalizedBlogs,
  blogSchema,
  NormalizedBlog,
  Entities,
} from "./schema";
import { store } from "../../../../store";
import blogAction from "../../../../features/blog/action";

const blogsData = [
  {
    id: 123,
    user: {
      id: 1,
      name: "Tom",
    },
    title: "引越し",
    body: "引越ししました",
    createdAt: dayjs(),
    comments: [
      {
        id: 324,
        body: "どこに？",
        createdAt: dayjs().add(3, "hour"),
        user: {
          id: 2,
          name: "Bob",
        },
      },
      {
        id: 325,
        body: "今度、家いかせて",
        createdAt: dayjs().add(5, "hour"),
        user: {
          id: 3,
          name: "Sam",
        },
      },
    ],
  },
];

export const getBlogs = (): Promise<NormalizedBlogs> => {
  const normalizedBlogs = normalize<
    NormalizedBlog,
    Entities,
    { blogs: number[] }
  >({ blogs: blogsData }, { blogs: [blogSchema] });
  store.dispatch(blogAction.set(normalizedBlogs));

  return Promise.resolve(normalizedBlogs);
};

こんな感じで、apiから取得してきた想定のブログのデータをnormalizeで正規化し、

  const normalizedBlogs = normalize<
    NormalizedBlog,
    Entities,
    { blogs: number[] }
  >({ blogs: blogsData }, { blogs: [blogSchema] });

正規化した値をストアに格納しています。

store.dispatch(blogAction.set(normalizedBlogs));

normalizrで正規化したデータはこんな感じになって、ストアに格納されます。apiからとってきたデータはネストした構造でしたが、ネストしていた部分は該当データへのid参照のみになっていることがわかります。

{
  "entities": {
    "users": {
      "1": {
        "id": 1,
        "name": "Tom"
      },
      "2": {
        "id": 2,
        "name": "Bob"
      },
      "3": {
        "id": 3,
        "name": "Sam"
      }
    },
    "comments": {
      "324": {
        "id": 324,
        "body": "どこに？",
        "createdAt": "2020-09-27T04:59:27.926Z",
        "user": 2
      },
      "325": {
        "id": 325,
        "body": "今度、家いかせて",
        "createdAt": "2020-09-27T06:59:27.927Z",
        "user": 3
      }
    },
    "blogs": {
      "123": {
        "id": 123,
        "user": 1,
        "title": "引越し",
        "body": "引越ししました",
        "createdAt": "2020-09-27T01:59:27.926Z",
        "comments": [
          324,
          325
        ]
      }
    }
  },
  "result": {
    "blogs": [
      123
    ]
  }
}

normalizrのスキーマ定義

normalizrで利用するスキーマや正規化、非正規化した後の型は自身で書く必要があります。
今回はこんな感じの型を用意しました。

src/domain/api/blog/get/schema.ts

import { schema, NormalizedSchema } from "normalizr";

type ListEntities<
  K extends string | number | symbol,
  T,
  U extends string
> = {
  [k in U]: Record<K, T>;
};


// apiレスポンス
export type BlogResponse = {
  id: number;
  user: {
    id: number;
    name: string;
  };
  title: string;
  comments: {
    id: number;
    body: string;
    user: {
      id: number;
      name: string;
    };
  }[];
};
export type BlogsResponse = BlogResponse[];

// normalizrで使うスキーマ
export const userSchema = new schema.Entity<NormalizedUser>("users");
export const commentSchema = new schema.Entity<Comment>("comments", {
  user: userSchema,
});
export const blogSchema = new schema.Entity<NormalizedBlog>("blogs", {
  user: userSchema,
  comments: [commentSchema],
});

// normalizeされた後の型定義
export type NormalizedBlogs = NormalizedSchema<Entities, { blogs: number[] }>;

export type Entities = BlogEntities & UserEntities & CommentEntities;

export interface NormalizedBlog {
  id: number;
  user: number;
  title: string;
  comments: number[];
}
export type BlogsStore = Record<number, NormalizedBlog>;
export type BlogEntities = ListEntities<number, NormalizedBlog, "blogs">;

export interface NormalizedComment {
  id: number;
  body: string;
  user: number;
}
export type CommentsStore = Record<number, NormalizedComment>;
export type CommentEntities = ListEntities<
  number,
  NormalizedComment,
  "comments"
>;

export interface NormalizedUser {
  id: number;
  name: string;
}
export type UsersStore = Record<number, NormalizedUser>;
export type UserEntities = ListEntities<number, NormalizedUser, "users">;

クリーンアーキテクチャ、DI

ドメインロジックをになっていく各層を作成していきます。
usecase層はreduxのストアに格納されている正規化したデータを引数としてもらい、そのデータを元にいろんなユースケースを実現していくイメージです。

│   ├── domain
│   │   ├── di           // diをする層
│   │   │   ├── blog.ts
│   │   │   └── index.ts
│   │   ├── model        // ドメインロジックを詰めるモデル層
│   │   │   └── blog
│   │   ├── repository   // reduxのstore情報を元にしてモデルを返す
│   │   │   ├── blog
│   │   │   └── index.ts
│   │   └── usecase      // ユースケース層
│   │       └── blog

usecase

usecaseに生えているメソッドが実際のコンポーネントから叩かれるメソッドになります。
こんな感じで、 Repository のinterfaceを満たすものをinjectionするようになっています。
findAll、findOneはBlogのモデルを返すようになっています。

src/domain/usecase/blog/index.ts

import { injectable, inject } from "tsyringe";
import type { Repository } from "../../repository";
import { Blog } from "../../model/blog/blog";
import { RootState } from "../../../store";

@injectable()
export default class BlogUseCase {
  constructor(@inject("BlogRepository") private repository: Repository) {}

  findAll(store: RootState["blog"]) {
    return this.repository.findAll<Blog>(store);
  }

  findOne(blogId: number, store: RootState["blog"]) {
    return this.repository.findOne<Blog>(blogId, store);
  }
}

Repositoryのinterfaceはこんな感じです。これを満たすものであればusecaseにdiすることができるようになります。

src/domain/repository/index.ts

export interface Repository {
  findAll<T>(store: any): Promise<T[]>;
  findOne<T>(id: number, store: any): Promise<T>;
}

今回はサンプルのアプリがシンプルすぎるので、usecaseのメソッド名とrepositoryのメソッド名が被ってますが、イメージ的にはユースケース層はいろんなrepository層をinjectionして、各モデルが協調して一つの処理を行うイメージです。
今回の例では、storeの値を引数に受け取り、モデルを返しているだけです。

repository

repositoryはreduxのストアの値を引数に、モデルを返します。モデルの生成はinjectionしているFactory層が担っています。
ストアの値は正規化されているので、このrepositoryの層で denormalize し、元のapiレスポンスの形に戻しています。
そのレスポンスを this.factory に渡すことでモデルが返ってきます。

import { injectable, inject } from "tsyringe";
import { denormalize } from "normalizr";
import { BlogResponse, blogSchema } from "../../api/blog/get/schema";
import type { Factory } from "../../model/blog/factory";
import type { Repository } from "..";
import type { RootState } from "../../../store";

@injectable()
export default class BlogRepository implements Repository {
  constructor(@inject("BlogFactory") private factory: Factory) {}

  findAll<T>(store: RootState["blog"]): Promise<T[]> {
    const denormalizedBlogs = denormalize(
      store.result.blogs,
      [blogSchema],
      store.entities
    );

    return Promise.all(
      denormalizedBlogs.map((blog: BlogResponse) => this.factory.create(blog))
    );
  }

  findOne<T>(id: number, store: RootState["blog"]): Promise<T> {
    const denormalizedBlog: BlogResponse = denormalize(
      id,
      blogSchema,
      store.entities
    );

    return this.factory.create(denormalizedBlog);
  }
}

Factoryのinterfaceはこんな感じです。
このinterfaceを満たすものであれば、repositoryにdiできます。

src/domain/model/blog/factory.ts

export interface Factory {
  create<T>(data: any): Promise<T>;
}

factory

factoryは引数でもらった非正規化したストアの値を元に、モデルを返します。
モデルの生成にclass-transformer、モデルのバリデーションにclass-validatorを使っています。

src/domain/model/blog/factory.ts

import { injectable } from "tsyringe";
import { plainToClass } from "class-transformer";
import { validate } from "class-validator";
import { Blog } from "./blog";
import type { BlogResponse } from "../../api/blog/get/schema";

export interface Factory {
  create<T>(data: any): Promise<T>;
}

@injectable()
export class BlogFactory {
  async create(denormalizedBlog: BlogResponse): Promise<Blog> {
    const model = plainToClass(Blog, denormalizedBlog);
    const errors = await validate(model);

    if (errors.length) {
      throw new Error(`モデルの作成に失敗しました。\n${errors}`);
    }

    return model;
  }
}

model

class-transformer、class-validatorを用いて生成するモデルです。
このモデルをコンポーネント上で扱って、画面を作っていくことになります。

src/domain/model/blog/blog.ts

import { Type } from "class-transformer";
import { IsInt, IsString, IsDateString, ValidateNested } from "class-validator";
import dayjs from "dayjs";
import { Author } from "./user";
import Comment from "./comment";

export class Blog {
  @IsInt()
  id: number;

  @Type(() => Author)
  @ValidateNested()
  user: Author;

  @IsString()
  title: string;

  @IsString()
  body: string;

  @Type(() => Comment)
  @ValidateNested()
  comments: Comment[];

  @IsDateString()
  createdAt: Date;

  get postDate(): string {
    return dayjs(this.createdAt).format("MMMM D, YYYY");
  }
}

src/domain/model/blog/comment.ts

import { Type } from "class-transformer";
import { IsInt, IsString, IsDateString, ValidateNested } from "class-validator";
import dayjs from "dayjs";
import { Commenter } from "./user";

export default class Comment {
  @IsInt()
  id: number;

  @IsString()
  body: string;

  @Type(() => Commenter)
  @ValidateNested()
  user: Commenter;

  @IsDateString()
  createdAt: Date;

  get postDate(): string {
    return dayjs(this.createdAt).format("MMMM D, YYYY");
  }
}

src/domain/model/blog/user.ts

import { IsInt, IsString } from "class-validator";

class User {
  @IsInt()
  id: number;

  @IsString()
  name: string;

  get initial(): string {
    return this.name[0];
  }
}

export class Author extends User {
  @IsInt()
  id: number;

  @IsString()
  name: string;
}

export class Commenter extends User {
  @IsInt()
  id: number;

  @IsString()
  name: string;
}

DI

作成したリポジトリ、ファクトリをDIして、ユースケースのインスタンスを生成する層です。

src/domain/di/blog.ts

import { container } from "tsyringe";
import BlogUseCase from "../usecase/blog";
import { BlogFactory } from "../model/blog/factory";
import BlogRepository from "../repository/blog";
import type { Repository } from "../repository";

export const NewBlogUseCase = () => {
  container.register("BlogFactory", { useClass: BlogFactory });
  container.register<Repository>("BlogRepository", {
    useClass: BlogRepository,
  });

  return container.resolve(BlogUseCase);
};

ユースケースを利用したい際に毎回 NewBlogUseCase を呼び出すのは手間です。
なので、ここで生成したユースケースのインスタンスはReactのContextに流し込み、利用したいコンポーネント上で取り出せるようにします。

ユースケースのインスタンスをまとめたエントリーポイントを作ります。

src/domain/di/index.ts

import { NewBlogUseCase } from "./blog";

export default {
  usecase: {
    blog: NewBlogUseCase(),
  },
};

上記のエントリーポイントを値としたContextを作り、カスタムフックとして利用できるようにします。

src/hooks/useDI.ts

import React, { useContext } from "react";
import di from "../domain/di";

export const DIContext = React.createContext(di);

export const useDIContext = () => {
  return useContext(DIContext);
};

src/index.tsx（抜粋）

import React from "react";
import App from "./App";
import { DIContext } from "./hooks/useDI";

ReactDOM.render(
  <DIContext.Provider value={di}>
    <App />
  </DIContext.Provider>
  document.getElementById("root")
);

使う側ではこのようにしてユースケースを利用できます。

const di = useDIContext();
di.usecase.blog.findAll(data)

非同期処理

非同期処理には、react-query、Suspense、ErrorBoundaryを利用しました。

react-queryのオプションでグローバルにsuspenceを有効化しておきます。

src/index.tsx(抜粋)

import React from "react";
import ReactDOM from "react-dom";
import { ReactQueryConfig, ReactQueryConfigProvider } from "react-query";
import App from "./App";

const queryConfig: ReactQueryConfig = {
  shared: {
    suspense: true,
  },
};

ReactDOM.render(
  <ReactQueryConfigProvider config={queryConfig}>
    <App />
  </ReactQueryConfigProvider>
  document.getElementById("root")
);

こんな感じでuseQueryを利用します。
useDIContextで取得してきたユースケースをuseQueryのfetcher引数に渡してデータを取得します。

src/components/containers/BlogDetail.tsx

import React, { FC } from "react";
import { getBlogs } from "../../domain/api/blog/get";
import { useQueryWithSuspense } from "../../hooks/useQueryWithSuspense";
import BlogList from "../oraganisms/BlogList";
import BlogUseCase from "../../domain/usecase/blog";
import { NormalizedBlogs } from "../../domain/api/blog/get/schema";
import { useDIContext } from "../../hooks/useDI";

const fetchBlogModels = (usecase: BlogUseCase) => {
  return async (data: NormalizedBlogs) => {
    return usecase.findAll(data);
  };
};

const BlogListContainer: FC = () => {
  const { data: blogsData } = useQueryWithSuspense("getBlogs", getBlogs);
  const di = useDIContext();
  const { data: blogs } = useQueryWithSuspense(
    [blogsData, "getBlogModels"],
    fetchBlogModels(di.usecase.blog)
  );

  return <BlogList blogs={blogs} />;
};

export default BlogListContainer;

useQueryのfetcherの関数を高階関数にしている理由は、当初以下のようにインスタンスのメソッドを素直にfetcherに渡していましたが、

  const { data: blogs } = useQueryWithSuspense(
    [blogsData, "getBlogModels"],
    di.usecase.blog.findAll
  );

どうやらインスタンスのメソッドを渡すのは無理っぽく、これではエラーになりました。そのため、高階関数を渡すようにしています。

また、 useQueryWithSuspense は独自に用意したカスタムフックです。useQueryの結果のdataがnullableの型で推論されるのが面倒だったので以下のようなフックを用意し、dataが必ずある状態の型が返って来るようにしました。
このフックはこちらの記事の実装をそのまま利用させていただきました。

src/hooks/useQueryWithSuspense.ts

import {
  useQuery,
  QueryFunction,
  QueryKey,
  QueryResult,
  QueryConfig,
} from "react-query";

type RequireData<T extends { data: unknown }> = T & {
  data: NonNullable<T["data"]>;
};

type UseQueryWithSuspenseResult<T> = RequireData<QueryResult<T, unknown>>;

export const useQueryWithSuspense = <T extends unknown>(
  queryKey: QueryKey,
  fetcher: QueryFunction<T>,
  queryConfig?: QueryConfig<T>
): UseQueryWithSuspenseResult<T> => {
  return useQuery(queryKey, fetcher, queryConfig) as any;
};

エラーハンドリング

非同期処理などのエラーハンドリング漏れを防ぐためにErrorBoundaryを利用しました。

こんな感じのコンポーネントを用意し、

src/ErrorBoundary.tsx

import React, { Component, ErrorInfo, ReactNode } from "react";

export interface Props {
  children: ReactNode;
}

export interface State {
  hasError: boolean;
  error: Error | null;
}

export default class ErrorBoundary extends Component<Props, State> {
  constructor(props: Props) {
    super(props);
    this.state = { hasError: false, error: null };
  }

  static getDerivedStateFromError(error: Error): State {
    return { hasError: true, error };
  }

  componentDidCatch(error: Error, errorInfo: ErrorInfo): void {
    console.log(error, errorInfo);
  }

  render(): ReactNode {
    const { hasError, error } = this.state;
    const { children } = this.props;
    if (hasError) {
      return <h1 style={{ whiteSpace: "pre-wrap" }}>{error?.message}</h1>;
    }

    return children;
  }
}

エラーハンドリングしたいコンポーネントをErrorBoundaryで包みます。

src/components/pages/Blog.tsx

import React, { Suspense } from "react";
import { Route, Routes } from "react-router";
import CircularProgress from "@material-ui/core/CircularProgress";
import BlogList from "../containers/BlogList";
import BlogDetail from "../containers/BlogDetail";
import ErrorBoundary from "../../ErrorBoundary";

function BlogPage() {
  return (
    <ErrorBoundary>
      <Routes>
        <Route
          path=""
          element={
            <Suspense fallback={<CircularProgress />}>
              <BlogList />
            </Suspense>
          }
        ></Route>
        <Route
          path=":blogId"
          element={
            <Suspense fallback={<CircularProgress />}>
              <BlogDetail />
            </Suspense>
          }
        />
      </Routes>
    </ErrorBoundary>
  );
}

export default BlogPage;

例として、モデルを生成する際バリデーションに失敗するとErrorをスローするようにしていました。

src/domain/model/blog/factory.ts（抜粋）

  async create(denormalizedBlog: BlogResponse): Promise<Blog> {
    const model = plainToClass(Blog, denormalizedBlog);
    console.log(model);

    const errors = await validate(model);

    if (errors.length) {
      throw new Error(`モデルの作成に失敗しました。\n${errors}`);
    }

    return model;
  }

意図的にモックのAPIレスポンスデータを不正な値にしてみます。

すると、こんな感じで、ErrorBoundaryでキャッチできていることがわかります。

ルーティング

ルーティングにはreact-router@v6を利用しました。
react-query、Suspenseの組み合わせで非同期処理をしていくのは今後増えていきそうですが、v5以前のreact-routerではSuspenseとの相性が悪いようで、react-query、Suspenseを使いたいならv6を入れておいた方が後々楽だと思います。参考

v6ではv3のときにあったようなルーティングを一箇所にネストして定義するやり方(nested routes)もできますし、v5の時のような各コンポーネントに分散してルーティングを書くこともできます。今回のサンプルアプリではv5の時のような各コンポーネントに分散して書く形で実装しました。

src/App.tsx

import React, { useEffect } from "react";
import { Route, Routes, useLocation, useNavigate } from "react-router";
import Blog from "./components/pages/Blog";
import "./App.css";

function App() {
  const { hash, pathname } = useLocation();
  const navigate = useNavigate();

  useEffect(() => {
    if (pathname === "/") {
      navigate("/blog");
    }
  }, [hash, pathname, navigate]);

  return (
    <Routes>
      <Route path="blog/*" element={<Blog />} />
    </Routes>
  );
}

export default App;

src/components/pages/Blog.tsx

import React, { Suspense } from "react";
import { Route, Routes } from "react-router";
import CircularProgress from "@material-ui/core/CircularProgress";
import BlogList from "../containers/BlogList";
import BlogDetail from "../containers/BlogDetail";
import ErrorBoundary from "../../ErrorBoundary";

function BlogPage() {
  return (
    <ErrorBoundary>
      <Routes>
        <Route
          path=""
          element={
            <Suspense fallback={<CircularProgress />}>
              <BlogList />
            </Suspense>
          }
        ></Route>
        <Route
          path=":blogId"
          element={
            <Suspense fallback={<CircularProgress />}>
              <BlogDetail />
            </Suspense>
          }
        />
      </Routes>
    </ErrorBoundary>
  );
}

export default BlogPage;

Redux toolkit

グローバルなstateの管理には@reduxjs/toolkitを利用しました。
普通にreduxを利用した場合はtypescriptとの相性やaction、reducerなどのボイラープレート的なコード量の多さに辟易していきますが、redux toolkitを利用した場合はそこらへんのめんどくささが結構解消されているため、使いやすく感じてます。（アクションとかは自分で書く必要はなくなるし、tsとの相性もいい）

ディレクトリ構造はfeaturesディレクトリのなかにactionとreducerをまとめるようにしています。

├── src

│   ├── features         // reduxのaction、reducer
│   │   └── blog
│   │       ├── action.ts
│   │       └── reducer.ts

src/features/blog/action.ts

import { NormalizedBlogs } from "../../domain/api/blog/get/schema";
import { RootState } from "../../store";
import { blogSlice } from "./reducer";

const { actions } = blogSlice;

export const selectBlog = (state: RootState): NormalizedBlogs => state.blog;

export const isEmpty = (state: RootState): boolean =>
  !!Object.keys(state.blog.entities.blogs).length;

export default actions;

src/features/blog/reducer.ts

import { createSlice, PayloadAction } from "@reduxjs/toolkit";
import { NormalizedBlogs } from "../../domain/api/blog/get/schema";

const initialState: NormalizedBlogs = {
  entities: {
    users: {},
    comments: {},
    blogs: {},
  },
  result: {
    blogs: [],
  },
};

export const blogSlice = createSlice({
  name: "blog",
  initialState,
  reducers: {
    set: (state, action: PayloadAction<NormalizedBlogs>): NormalizedBlogs => {
      return { ...state, ...action.payload };
    },
  },
});

export default blogSlice.reducer;

最後に

今回思いつきで作ってみましたが、実際にこのアーキテクチャで業務コードを書いたことはないため、スケールしていくコードにどれだけ耐えれる設計なのかは実際に試してみようと思いました。
また、normalizrは実際業務で使ったことはなく、初めて使ってみたのですがスキーマなどの型定義が結構めんどくさく、「ストアの正規化ってそこまで恩恵あるのかな？？」と懐疑的な気持ちになりました。

はじめに

以下のような考えを満たすような環境を作ってみました。

• フロントエンドの環境でもクリーンアーキテクチャのようなことをしたい
• 非同期処理はモダンなreact-queryで書きたい
• 今まで慣れ親しんだreduxも入れときたい

コードはこちらにあります
https://github.com/pokotyan/clean-architecture-front

利用パッケージ

利用した主なパッケージなどは以下の通りです。

• tsyringe
  diに利用。typediやinversifyでも同じことができると思います。

• Context
  diコンテナーとして利用

• class-transformer、class-validator
  モデルの生成、バリデーションに利用

• @reduxjs/toolkit
  reduxの導入に利用。グローバルなstateの管理をする

• normalizr
  reduxのストアの正規化に利用

• react-query、Suspense、ErrorBoundary
  非同期処理、エラーハンドリングに利用

• react-router@v6
  ルーティングに利用。v6のインストールは現状 @next を指定する必要があります。
  Suspenceをつかった非同期処理を行う場合、v5以前のものでは相性が悪いらしく、v6を利用しました。参考

作ったアプリ

サンプルとして作ったものは、以下のようなダミーのデータを元に一覧ページ、詳細ページが閲覧できるものです。

データ

src/domain/api/blog/get/index.ts

const blogsData = [
  {
    id: 123,
    user: {
      id: 1,
      name: "Tom",
    },
    title: "引越し",
    body: "引越ししました",
    createdAt: dayjs(),
    comments: [
      {
        id: 324,
        body: "どこに？",
        createdAt: dayjs().add(3, "hour"),
        user: {
          id: 2,
          name: "Bob",
        },
      },
      {
        id: 325,
        body: "今度、家いかせて",
        createdAt: dayjs().add(5, "hour"),
        user: {
          id: 3,
          name: "Sam",
        },
      },
    ],
  },
];

一覧ページ

詳細ページ

ディレクトリ構成

ディレクトリ構成はこんな感じです。

├── src
│   ├── App.tsx
│   ├── ErrorBoundary.tsx // エラーハンドリングのためのコンポーネント
│   ├── components
│   │   ├── containers  // データとコンポーネントの受け渡しをする層
│   │   │   ├── BlogDetail.tsx
│   │   │   └── BlogList.tsx
│   │   ├── oraganisms  // propsでもらったデータをただ表示するコンポーネント
│   │   │   ├── BlogDetail.tsx
│   │   │   └── BlogList.tsx
│   │   └── pages       // ページのコンポーネント
│   │       └── Blog.tsx
│   ├── domain
│   │   ├── api          // apiを叩いてデータを取って来る層
│   │   │   ├── blog
│   │   │   └── schema.ts
│   │   ├── di           // diをする層
│   │   │   ├── blog.ts
│   │   │   └── index.ts
│   │   ├── model        // ドメインロジックを詰めるモデル層
│   │   │   └── blog
│   │   ├── repository   // reduxのstore情報を元にしてモデルを返す
│   │   │   ├── blog
│   │   │   └── index.ts
│   │   └── usecase      // ユースケース層
│   │       └── blog
│   ├── features         // reduxのaction、reducer
│   │   └── blog
│   │       ├── action.ts
│   │       └── reducer.ts
│   ├── hooks            // カスタムフック
│   │   ├── useDI.ts
│   │   └── useQueryWithSuspense.ts
│   ├── index.tsx
│   └── store.ts         // reduxのstore生成

ここからは順を追って、それぞれのディレクトリの処理を見ていきます。

apiからのデータ取得、正規化、reduxのストアへの格納

getBlogs関数は、apiからデータを取得してきたていの関数です。モックのデータをPromiseに包んで返します。

取得したデータはreduxのストアに格納します。
reduxのストアにはapiから取得したデータをそのまま格納するのではなく、正規化した値を入れるのがいいとされているのでそのようにしました。参考

正規化した値を入れることで、データのネスト構造が浅く保てるので、reducerで更新処理がわかりやすくなります。
正規化にはnormalizrを利用しました。

src/domain/api/blog/get/index.ts

import { normalize } from "normalizr";
import dayjs from "dayjs";
import {
  NormalizedBlogs,
  blogSchema,
  NormalizedBlog,
  Entities,
} from "./schema";
import { store } from "../../../../store";
import blogAction from "../../../../features/blog/action";

const blogsData = [
  {
    id: 123,
    user: {
      id: 1,
      name: "Tom",
    },
    title: "引越し",
    body: "引越ししました",
    createdAt: dayjs(),
    comments: [
      {
        id: 324,
        body: "どこに？",
        createdAt: dayjs().add(3, "hour"),
        user: {
          id: 2,
          name: "Bob",
        },
      },
      {
        id: 325,
        body: "今度、家いかせて",
        createdAt: dayjs().add(5, "hour"),
        user: {
          id: 3,
          name: "Sam",
        },
      },
    ],
  },
];

export const getBlogs = (): Promise<NormalizedBlogs> => {
  const normalizedBlogs = normalize<
    NormalizedBlog,
    Entities,
    { blogs: number[] }
  >({ blogs: blogsData }, { blogs: [blogSchema] });
  store.dispatch(blogAction.set(normalizedBlogs));

  return Promise.resolve(normalizedBlogs);
};

こんな感じで、apiから取得してきた想定のブログのデータをnormalizeで正規化し、

  const normalizedBlogs = normalize<
    NormalizedBlog,
    Entities,
    { blogs: number[] }
  >({ blogs: blogsData }, { blogs: [blogSchema] });

正規化した値をストアに格納しています。

store.dispatch(blogAction.set(normalizedBlogs));

normalizrで正規化したデータはこんな感じになって、ストアに格納されます。apiからとってきたデータはネストした構造でしたが、ネストしていた部分は該当データへのid参照のみになっていることがわかります。

{
  "entities": {
    "users": {
      "1": {
        "id": 1,
        "name": "Tom"
      },
      "2": {
        "id": 2,
        "name": "Bob"
      },
      "3": {
        "id": 3,
        "name": "Sam"
      }
    },
    "comments": {
      "324": {
        "id": 324,
        "body": "どこに？",
        "createdAt": "2020-09-27T04:59:27.926Z",
        "user": 2
      },
      "325": {
        "id": 325,
        "body": "今度、家いかせて",
        "createdAt": "2020-09-27T06:59:27.927Z",
        "user": 3
      }
    },
    "blogs": {
      "123": {
        "id": 123,
        "user": 1,
        "title": "引越し",
        "body": "引越ししました",
        "createdAt": "2020-09-27T01:59:27.926Z",
        "comments": [
          324,
          325
        ]
      }
    }
  },
  "result": {
    "blogs": [
      123
    ]
  }
}

normalizrのスキーマ定義

normalizrで利用するスキーマや正規化、非正規化した後の型は自身で書く必要があります。
今回はこんな感じの型を用意しました。

src/domain/api/blog/get/schema.ts

import { schema, NormalizedSchema } from "normalizr";

type ListEntities<
  K extends string | number | symbol,
  T,
  U extends string
> = {
  [k in U]: Record<K, T>;
};


// apiレスポンス
export type BlogResponse = {
  id: number;
  user: {
    id: number;
    name: string;
  };
  title: string;
  comments: {
    id: number;
    body: string;
    user: {
      id: number;
      name: string;
    };
  }[];
};
export type BlogsResponse = BlogResponse[];

// normalizrで使うスキーマ
export const userSchema = new schema.Entity<NormalizedUser>("users");
export const commentSchema = new schema.Entity<Comment>("comments", {
  user: userSchema,
});
export const blogSchema = new schema.Entity<NormalizedBlog>("blogs", {
  user: userSchema,
  comments: [commentSchema],
});

// normalizeされた後の型定義
export type NormalizedBlogs = NormalizedSchema<Entities, { blogs: number[] }>;

export type Entities = BlogEntities & UserEntities & CommentEntities;

export interface NormalizedBlog {
  id: number;
  user: number;
  title: string;
  comments: number[];
}
export type BlogsStore = Record<number, NormalizedBlog>;
export type BlogEntities = ListEntities<number, NormalizedBlog, "blogs">;

export interface NormalizedComment {
  id: number;
  body: string;
  user: number;
}
export type CommentsStore = Record<number, NormalizedComment>;
export type CommentEntities = ListEntities<
  number,
  NormalizedComment,
  "comments"
>;

export interface NormalizedUser {
  id: number;
  name: string;
}
export type UsersStore = Record<number, NormalizedUser>;
export type UserEntities = ListEntities<number, NormalizedUser, "users">;

クリーンアーキテクチャ、DI

ドメインロジックをになっていく各層を作成していきます。
usecase層はreduxのストアに格納されている正規化したデータを引数としてもらい、そのデータを元にいろんなユースケースを実現していくイメージです。

│   ├── domain
│   │   ├── di           // diをする層
│   │   │   ├── blog.ts
│   │   │   └── index.ts
│   │   ├── model        // ドメインロジックを詰めるモデル層
│   │   │   └── blog
│   │   ├── repository   // reduxのstore情報を元にしてモデルを返す
│   │   │   ├── blog
│   │   │   └── index.ts
│   │   └── usecase      // ユースケース層
│   │       └── blog

usecase

usecaseに生えているメソッドが実際のコンポーネントから叩かれるメソッドになります。
こんな感じで、 Repository のinterfaceを満たすものをinjectionするようになっています。
findAll、findOneはBlogのモデルを返すようになっています。

src/domain/usecase/blog/index.ts

import { injectable, inject } from "tsyringe";
import type { Repository } from "../../repository";
import { Blog } from "../../model/blog/blog";
import { RootState } from "../../../store";

@injectable()
export default class BlogUseCase {
  constructor(@inject("BlogRepository") private repository: Repository) {}

  findAll(store: RootState["blog"]) {
    return this.repository.findAll<Blog>(store);
  }

  findOne(blogId: number, store: RootState["blog"]) {
    return this.repository.findOne<Blog>(blogId, store);
  }
}

Repositoryのinterfaceはこんな感じです。これを満たすものであればusecaseにdiすることができるようになります。

src/domain/repository/index.ts

export interface Repository {
  findAll<T>(store: any): Promise<T[]>;
  findOne<T>(id: number, store: any): Promise<T>;
}

今回はサンプルのアプリがシンプルすぎるので、usecaseのメソッド名とrepositoryのメソッド名が被ってますが、イメージ的にはユースケース層はいろんなrepository層をinjectionして、各モデルが協調して一つの処理を行うイメージです。
今回の例では、storeの値を引数に受け取り、モデルを返しているだけです。

repository

repositoryはreduxのストアの値を引数に、モデルを返します。モデルの生成はinjectionしているFactory層が担っています。
ストアの値は正規化されているので、このrepositoryの層で denormalize し、元のapiレスポンスの形に戻しています。
そのレスポンスを this.factory に渡すことでモデルが返ってきます。

import { injectable, inject } from "tsyringe";
import { denormalize } from "normalizr";
import { BlogResponse, blogSchema } from "../../api/blog/get/schema";
import type { Factory } from "../../model/blog/factory";
import type { Repository } from "..";
import type { RootState } from "../../../store";

@injectable()
export default class BlogRepository implements Repository {
  constructor(@inject("BlogFactory") private factory: Factory) {}

  findAll<T>(store: RootState["blog"]): Promise<T[]> {
    const denormalizedBlogs = denormalize(
      store.result.blogs,
      [blogSchema],
      store.entities
    );

    return Promise.all(
      denormalizedBlogs.map((blog: BlogResponse) => this.factory.create(blog))
    );
  }

  findOne<T>(id: number, store: RootState["blog"]): Promise<T> {
    const denormalizedBlog: BlogResponse = denormalize(
      id,
      blogSchema,
      store.entities
    );

    return this.factory.create(denormalizedBlog);
  }
}

Factoryのinterfaceはこんな感じです。
このinterfaceを満たすものであれば、repositoryにdiできます。

src/domain/model/blog/factory.ts

export interface Factory {
  create<T>(data: any): Promise<T>;
}

factory

factoryは引数でもらった非正規化したストアの値を元に、モデルを返します。
モデルの生成にclass-transformer、モデルのバリデーションにclass-validatorを使っています。

src/domain/model/blog/factory.ts

import { injectable } from "tsyringe";
import { plainToClass } from "class-transformer";
import { validate } from "class-validator";
import { Blog } from "./blog";
import type { BlogResponse } from "../../api/blog/get/schema";

export interface Factory {
  create<T>(data: any): Promise<T>;
}

@injectable()
export class BlogFactory {
  async create(denormalizedBlog: BlogResponse): Promise<Blog> {
    const model = plainToClass(Blog, denormalizedBlog);
    const errors = await validate(model);

    if (errors.length) {
      throw new Error(`モデルの作成に失敗しました。\n${errors}`);
    }

    return model;
  }
}

model

class-transformer、class-validatorを用いて生成するモデルです。
このモデルをコンポーネント上で扱って、画面を作っていくことになります。

src/domain/model/blog/blog.ts

import { Type } from "class-transformer";
import { IsInt, IsString, IsDateString, ValidateNested } from "class-validator";
import dayjs from "dayjs";
import { Author } from "./user";
import Comment from "./comment";

export class Blog {
  @IsInt()
  id: number;

  @Type(() => Author)
  @ValidateNested()
  user: Author;

  @IsString()
  title: string;

  @IsString()
  body: string;

  @Type(() => Comment)
  @ValidateNested()
  comments: Comment[];

  @IsDateString()
  createdAt: Date;

  get postDate(): string {
    return dayjs(this.createdAt).format("MMMM D, YYYY");
  }
}

src/domain/model/blog/comment.ts

import { Type } from "class-transformer";
import { IsInt, IsString, IsDateString, ValidateNested } from "class-validator";
import dayjs from "dayjs";
import { Commenter } from "./user";

export default class Comment {
  @IsInt()
  id: number;

  @IsString()
  body: string;

  @Type(() => Commenter)
  @ValidateNested()
  user: Commenter;

  @IsDateString()
  createdAt: Date;

  get postDate(): string {
    return dayjs(this.createdAt).format("MMMM D, YYYY");
  }
}

src/domain/model/blog/user.ts

import { IsInt, IsString } from "class-validator";

class User {
  @IsInt()
  id: number;

  @IsString()
  name: string;

  get initial(): string {
    return this.name[0];
  }
}

export class Author extends User {
  @IsInt()
  id: number;

  @IsString()
  name: string;
}

export class Commenter extends User {
  @IsInt()
  id: number;

  @IsString()
  name: string;
}

DI

作成したリポジトリ、ファクトリをDIして、ユースケースのインスタンスを生成する層です。

src/domain/di/blog.ts

import { container } from "tsyringe";
import BlogUseCase from "../usecase/blog";
import { BlogFactory } from "../model/blog/factory";
import BlogRepository from "../repository/blog";
import type { Repository } from "../repository";

export const NewBlogUseCase = () => {
  container.register("BlogFactory", { useClass: BlogFactory });
  container.register<Repository>("BlogRepository", {
    useClass: BlogRepository,
  });

  return container.resolve(BlogUseCase);
};

ユースケースを利用したい際に毎回 NewBlogUseCase を呼び出すのは手間です。
なので、ここで生成したユースケースのインスタンスはReactのContextに流し込み、利用したいコンポーネント上で取り出せるようにします。

ユースケースのインスタンスをまとめたエントリーポイントを作ります。

src/domain/di/index.ts

import { NewBlogUseCase } from "./blog";

export default {
  usecase: {
    blog: NewBlogUseCase(),
  },
};

上記のエントリーポイントを値としたContextを作り、カスタムフックとして利用できるようにします。

src/hooks/useDI.ts

import React, { useContext } from "react";
import di from "../domain/di";

export const DIContext = React.createContext(di);

export const useDIContext = () => {
  return useContext(DIContext);
};

src/index.tsx（抜粋）

import React from "react";
import App from "./App";
import { DIContext } from "./hooks/useDI";

ReactDOM.render(
  <DIContext.Provider value={di}>
    <App />
  </DIContext.Provider>
  document.getElementById("root")
);

使う側ではこのようにしてユースケースを利用できます。

const di = useDIContext();
di.usecase.blog.findAll(data)

非同期処理

非同期処理には、react-query、Suspenseを利用しました。

react-query

react-queryのオプションでグローバルにsuspenceを有効化しておきます。

src/index.tsx(抜粋)

import React from "react";
import ReactDOM from "react-dom";
import { ReactQueryConfig, ReactQueryConfigProvider } from "react-query";
import App from "./App";

const queryConfig: ReactQueryConfig = {
  shared: {
    suspense: true,
  },
};

ReactDOM.render(
  <ReactQueryConfigProvider config={queryConfig}>
    <App />
  </ReactQueryConfigProvider>
  document.getElementById("root")
);

こんな感じでuseQueryを利用します。
useDIContextで取得してきたユースケースをuseQueryのfetcher引数に渡してデータを取得します。

src/components/containers/BlogDetail.tsx

import React, { FC } from "react";
import { getBlogs } from "../../domain/api/blog/get";
import { useQueryWithSuspense } from "../../hooks/useQueryWithSuspense";
import BlogList from "../oraganisms/BlogList";
import BlogUseCase from "../../domain/usecase/blog";
import { NormalizedBlogs } from "../../domain/api/blog/get/schema";
import { useDIContext } from "../../hooks/useDI";

const fetchBlogModels = (usecase: BlogUseCase) => {
  return async (data: NormalizedBlogs) => {
    return usecase.findAll(data);
  };
};

const BlogListContainer: FC = () => {
  const { data: blogsData } = useQueryWithSuspense("getBlogs", getBlogs);
  const di = useDIContext();
  const { data: blogs } = useQueryWithSuspense(
    [blogsData, "getBlogModels"],
    fetchBlogModels(di.usecase.blog)
  );

  return <BlogList blogs={blogs} />;
};

export default BlogListContainer;

useQueryのfetcherの関数を高階関数にしている理由は、当初以下のようにインスタンスのメソッドを素直にfetcherに渡していましたが、

  const { data: blogs } = useQueryWithSuspense(
    [blogsData, "getBlogModels"],
    di.usecase.blog.findAll
  );

どうやらインスタンスのメソッドを渡すのは無理っぽく、これではエラーになりました。そのため、高階関数を渡すようにしています。

また、 useQueryWithSuspense は独自に用意したカスタムフックです。useQueryの結果のdataがnullableの型で推論されるのが面倒だったので以下のようなフックを用意し、dataが必ずある状態の型が返って来るようにしました。
このフックはこちらの記事の実装をそのまま利用させていただきました。

src/hooks/useQueryWithSuspense.ts

import {
  useQuery,
  QueryFunction,
  QueryKey,
  QueryResult,
  QueryConfig,
} from "react-query";

type RequireData<T extends { data: unknown }> = T & {
  data: NonNullable<T["data"]>;
};

type UseQueryWithSuspenseResult<T> = RequireData<QueryResult<T, unknown>>;

export const useQueryWithSuspense = <T extends unknown>(
  queryKey: QueryKey,
  fetcher: QueryFunction<T>,
  queryConfig?: QueryConfig<T>
): UseQueryWithSuspenseResult<T> => {
  return useQuery(queryKey, fetcher, queryConfig) as any;
};

Suspense

react-queryで非同期処理を行っているコンポーネントをSuspenseで囲ってあげることで、apiのデータ取得中は fallback に指定したコンポーネントが表示されます。ここではグルグル回るスピナーを表示するようにしています。

src/components/pages/Blog.tsx（抜粋）

import React, { Suspense } from "react";
import CircularProgress from "@material-ui/core/CircularProgress";
import BlogList from "../containers/BlogList";
import BlogDetail from "../containers/BlogDetail";

function BlogPage() {
  return (
    ...
            <Suspense fallback={<CircularProgress />}>
              <BlogList />
            </Suspense>
    ...
            <Suspense fallback={<CircularProgress />}>
              <BlogDetail />
            </Suspense>
    ...
  );
}

エラーハンドリング

非同期処理などのエラーハンドリング漏れを防ぐためにErrorBoundaryを利用しました。

こんな感じのコンポーネントを用意し、

src/ErrorBoundary.tsx

import React, { Component, ErrorInfo, ReactNode } from "react";

export interface Props {
  children: ReactNode;
}

export interface State {
  hasError: boolean;
  error: Error | null;
}

export default class ErrorBoundary extends Component<Props, State> {
  constructor(props: Props) {
    super(props);
    this.state = { hasError: false, error: null };
  }

  static getDerivedStateFromError(error: Error): State {
    return { hasError: true, error };
  }

  componentDidCatch(error: Error, errorInfo: ErrorInfo): void {
    console.log(error, errorInfo);
  }

  render(): ReactNode {
    const { hasError, error } = this.state;
    const { children } = this.props;
    if (hasError) {
      return <h1 style={{ whiteSpace: "pre-wrap" }}>{error?.message}</h1>;
    }

    return children;
  }
}

エラーハンドリングしたいコンポーネントをErrorBoundaryで包みます。

src/components/pages/Blog.tsx

import React, { Suspense } from "react";
import { Route, Routes } from "react-router";
import CircularProgress from "@material-ui/core/CircularProgress";
import BlogList from "../containers/BlogList";
import BlogDetail from "../containers/BlogDetail";
import ErrorBoundary from "../../ErrorBoundary";

function BlogPage() {
  return (
    <ErrorBoundary>
      <Routes>
        <Route
          path=""
          element={
            <Suspense fallback={<CircularProgress />}>
              <BlogList />
            </Suspense>
          }
        ></Route>
        <Route
          path=":blogId"
          element={
            <Suspense fallback={<CircularProgress />}>
              <BlogDetail />
            </Suspense>
          }
        />
      </Routes>
    </ErrorBoundary>
  );
}

export default BlogPage;

ErrorBoundaryでエラーハンドリングをする例として、モデルを生成する際バリデーションに失敗するとErrorをスローするようにしていました。ここでエラーを起こしてみて、どうなるか確認します。

src/domain/model/blog/factory.ts（抜粋）

  async create(denormalizedBlog: BlogResponse): Promise<Blog> {
    const model = plainToClass(Blog, denormalizedBlog);
    console.log(model);

    const errors = await validate(model);

    if (errors.length) {
      throw new Error(`モデルの作成に失敗しました。\n${errors}`);
    }

    return model;
  }

意図的にモックのAPIレスポンスデータを不正な値にしてみます。

すると、こんな感じで、ErrorBoundaryでキャッチできていることがわかります。

ルーティング

ルーティングにはreact-router@v6を利用しました。
react-query、Suspenseの組み合わせで非同期処理をしていくのは今後増えていきそうですが、v5以前のreact-routerではSuspenseとの相性が悪いようで、react-query、Suspenseを使いたいならv6を入れておいた方が後々楽だと思います。参考

v6ではv3のときにあったようなルーティングを一箇所にネストして定義するやり方(nested routes)もできますし、v5の時のような各コンポーネントに分散してルーティングを書くこともできます。今回のサンプルアプリではv5の時のような各コンポーネントに分散して書く形で実装しました。

src/App.tsx

import React, { useEffect } from "react";
import { Route, Routes, useLocation, useNavigate } from "react-router";
import Blog from "./components/pages/Blog";
import "./App.css";

function App() {
  const { hash, pathname } = useLocation();
  const navigate = useNavigate();

  useEffect(() => {
    if (pathname === "/") {
      navigate("/blog");
    }
  }, [hash, pathname, navigate]);

  return (
    <Routes>
      <Route path="blog/*" element={<Blog />} />
    </Routes>
  );
}

export default App;

src/components/pages/Blog.tsx

import React, { Suspense } from "react";
import { Route, Routes } from "react-router";
import CircularProgress from "@material-ui/core/CircularProgress";
import BlogList from "../containers/BlogList";
import BlogDetail from "../containers/BlogDetail";
import ErrorBoundary from "../../ErrorBoundary";

function BlogPage() {
  return (
    <ErrorBoundary>
      <Routes>
        <Route
          path=""
          element={
            <Suspense fallback={<CircularProgress />}>
              <BlogList />
            </Suspense>
          }
        ></Route>
        <Route
          path=":blogId"
          element={
            <Suspense fallback={<CircularProgress />}>
              <BlogDetail />
            </Suspense>
          }
        />
      </Routes>
    </ErrorBoundary>
  );
}

export default BlogPage;

Redux toolkit

グローバルなstateの管理には@reduxjs/toolkitを利用しました。
普通にreduxを利用した場合はtypescriptとの相性やaction、reducerなどのボイラープレート的なコード量の多さに辟易していきますが、redux toolkitを利用した場合はそこらへんのめんどくささが結構解消されているため、使いやすく感じてます。（アクションとかは自分で書く必要はなくなるし、tsとの相性もいい）

ディレクトリ構造はfeaturesディレクトリのなかにactionとreducerをまとめるようにしています。

├── src

│   ├── features         // reduxのaction、reducer
│   │   └── blog
│   │       ├── action.ts
│   │       └── reducer.ts

action

src/features/blog/action.ts

import { NormalizedBlogs } from "../../domain/api/blog/get/schema";
import { RootState } from "../../store";
import { blogSlice } from "./reducer";

const { actions } = blogSlice;

export const selectBlog = (state: RootState): NormalizedBlogs => state.blog;

export const isEmpty = (state: RootState): boolean =>
  !!Object.keys(state.blog.entities.blogs).length;

export default actions;

reducer

src/features/blog/reducer.ts

import { createSlice, PayloadAction } from "@reduxjs/toolkit";
import { NormalizedBlogs } from "../../domain/api/blog/get/schema";

const initialState: NormalizedBlogs = {
  entities: {
    users: {},
    comments: {},
    blogs: {},
  },
  result: {
    blogs: [],
  },
};

export const blogSlice = createSlice({
  name: "blog",
  initialState,
  reducers: {
    set: (state, action: PayloadAction<NormalizedBlogs>): NormalizedBlogs => {
      return { ...state, ...action.payload };
    },
  },
});

export default blogSlice.reducer;

今回のアプリの設計では、reduxのstoreにはnormalizrで正規化したデータを格納します。
そのため、stateのinitialStateの型は正規化したデータの型を指定しています。

src/features/blog/reducer.ts（抜粋）

import { NormalizedBlogs } from "../../domain/api/blog/get/schema";

const initialState: NormalizedBlogs = {
  entities: {
    users: {},
    comments: {},
    blogs: {},
  },
  result: {
    blogs: [],
  },
};

最後に

今回思いつきで作ってみましたが、実際にこのアーキテクチャで業務コードを書いたことはないため、スケールしていくコードにどれだけ耐えれる設計なのかは実際に試してみようと思いました。
また、normalizrは実際業務で使ったことはなく、初めて使ってみたのですがスキーマなどの型定義が結構めんどくさく、「ストアの正規化ってそこまで恩恵あるのかな？？」と懐疑的な気持ちになりました。