reduxモリモリのプロジェクトをリファクタリングする

前職での経験談兼反省談

redux は悪である。使わないようにしましょう。と言いたいわけではない。

あくまで私自身の使い方やプロジェクトでの設計が良くなかったため負債となる結果になってしったが、redux が react 界隈にもたらした恩恵と影響は大きいと考えており、redux がなければ react もフロントエンドもここまで大きなコミュニティにならなかったと言っても過言ではないと思っている。

プロジェクトの実情

開発初期にジョインする

何を作るかは決まっている

BtoB 向けのドキュメントツール兼チーム内のドキュメント共有サービス

とある条件で自動的にドキュメントと文章をリンクするというのがサービスの特色

WYSIWYGエディター

投資家に見てもらい投資の可否を仰ぐ必要がある

そのため要件を満たす試作品が必要

ユーザー(投資家)にどのようにして使うか(ドキュメントおよび口頭での説明)と、実際に触って動かせる実物が必要であった

サーバーサイド 0 人

フロントエンドだけで実装する という結論に至る

最初は投資が決定したら作り直す想定

結局は使い回すことになる

状態管理およびとして redux をモリモリ使った

サーバーから取得したと仮定した initialData や、状態を操作した後に操作後の状態を一時保存する必要性があった

サーバーが無いのにどうやって動かしたか

WebAPI などのバックエンドからデータを受け取るかわりに、initialState としてデータをメモリ内に保持しておき、それらのデータを閲覧したり、変更や削除、作成の機能を実装し、簡易的に CRUD 機能を代用していた

もちろんデータベースにデータを永続化していないので、画面をリロードすれば変更内容は初期化される

問題点

グローバルな値だけでなく親子コンポーネント間で使いたい状態も含めreduxで管理していた

code:typescript

const store = {

user: {

name: string;

company: string;

companyCode: string;

...

},

document: {

id: string;

body: string;

...

},

workspace: {

id: string;

thumbnail: string;

...

},

...

}

グローバルな値(ユーザー情報、画面に出力するエラーやアラート(modalなど))だけreduxを使えば管理がまだ楽だったはず

それ以外でもコンポーネントをまたいで使いたいstateは存在した

headerのツールバーからエディタ画面の文字を装飾するボタン、redo, undeボタンなど

テストを書く知識経験もなく、時間的制約もありコストをかけられなかった

受け入れテストとして最新mainブランチで、手動でのQAを週一程度行う

上の理由で管理対象に伴いファイル数が激増して保守性が低くなった

修正点

ページをまたぐstateの状態はreduxに持たせる

user情報など

ページ内に収まるstateの状態はuseContextに持たせる

確かにreduxのコードは減ったが受けた恩恵は多くはなかった

その後

試作品は認められ無事投資を受けること決定！

サーバーを書けるエンジニアも補充！！

サーバーとクライアントに分離に伴いreduxを剥がす作業が始まる

こうすればよかったのでは？

mswを使って開発時にサーバーがなくてもモックを使ってデータのCRUDをできるようにする

ユニットテスト

とはいえ、学習コストが高く当時はきつかった

関数など簡単にできるところからテストを書けばよかった

nextjsのAPIルート機能を使って簡易サーバーを立てる？