Yuuniworks Notes

# Redux - Style Guide

# 絶対に守ること

# state を改変しない

  • あらゆるバグのもとになる
  • redux-immutable-state-invariantやimmerなどのツールを活用せよ

# reducers に side effect を記載しない

  • reducer の結果は state と action にのみ依存すること
  • 下記のようなものを reducer に記載しないこと
    • ajax, timeout, promise などの非同期処理
    • Date.now()などの乱数生成

# シリアライズ出来ない値を state や action に含めない

  • Promise, Symbols, Maps/Sets, Functions, Class instances など
  • ただし reducer に届くまでにredux-thunkなどのミドルウェアで処理される場合は除く

# 複数の store を作らない

# 強い推奨事項

# Redux Toolkit を使え

ベストプラクティスが詰まっている

# immer を使え

rtk に含まれているよ

# フォルダ構成は Feature Folders か、少なくとも Ducks にせよ

  • ファイルの種類(reducers, actions, etc)でフォルダ分けするな
  • Feature Folders --- 特定の機能に関する全てのファイルを一つのフォルダにまとめる
  • Ducks --- 特定の機能のうち redux に関する部分のみを一つのフォルダにまとめる

# なるべく多くのロジックを reducers に集約せよ

  • action の発出側(コンポーネント)ではなく、reducer 側に積極的にロジックを記載せよ
  • これによりテスト性やデバッグの容易さが高まるうえ、ミスも減る
  • 発出側でしか行えない処理もあるが、最小限におさえること。
    • e.g. id の採番など

# reducer で state の構造をしっかり管理せよ

  • Reducer の責務
    • 初期値を決定する
    • state を正しい形式に維持する(必要に応じて action.payload のバリデーションを行うなど)
  • blind spreadreturn {...state, ...action.payload}や、blind return return action.payloadは避けること。
    • これは state の形式を決定する責務が action 発出側に漏れ出している状態であるため
    • ただし、フォーム内のデータを編集する際は使って良いかも
      • 要素ごとに action creators を書くのは時間の無駄だから
  • 利便性の観点から、単一の root reducer ではなく、複数の slice reducer で state を管理すると良い

# state の slice 名は格納するデータの名前にせよ

  • {users: {}, posts: {}}がよい
  • {usersReducer: {}, postsReducer: {}}はだめ

# state は データの種類により分けろ（UI で分けない）

  • なぜなら、UI と、UI が必要とするデータは、必ずしも 1 対 1 で結びつかないので
  • e.g. auth, posts, users, ui
    • 上記のauth等は複数の画面からアクセスされる
    • UI ごとの state はui配下に配置するとよい
  • (これは議論の余地がありそう)

# reducer を state machines として扱え

  • 通常は action だけを見て無条件で値を更新しがちだが、これはバグを生みやすい
  • state を考慮しながら、値を更新するかどうかを決定するとよい(これを state machine という)
    • 例えば、読み込み状態が'loading'なのに新しいデータが飛んできた場合は無視する、など

# ネストしたデータは正規化して管理せよ

  • 簡単にルックアップできる
  • 更新が簡単
  • 良いパフォーマンス

# state は最小限にせよ、必要なら派生データを作れ

  • e.g. filtered lists or summing up values
  • そうすれば
    • state が読みやすくなる
    • 派生データを作るためのロジックを減らせる
    • 派生データを多くの箇所で使った時に、同期が容易になる
    • オリジナル state やその参照を、変更せずに残すことができる

# action はイベントとして扱え。セッターとして使うな。

  • 「何が起こったか」で命名する action.payload === 'user/nameUpdated'
    • 意味がわかりやすい
    • dispatch される action の数が減る
    • ログが見やすい
  • セッターとして命名しない action.payload === 'user/setNewName'

# 意味のあるアクション名にする

  • SET_DATAやUPDATE_STOREといった無意味な名前にしない

# 単一のアクションに複数の reducer が反応する構成を検討する

  • スケールしやすい
  • 発出すべき action の数を減らせる

# 複数の action を順番に発出しない

  • なぜダメか
    • ハイコストな UI アップデートを引き起こす
    • action と action の中間で、おかしな state になる可能性がある
  • なるべく一発の action で全てを更新せよ
  • どうしても必要な場合はreact-reduxのbatch()を使え(React18 では不要)
    batch(() => {
  dispatch(increment());
  dispatch(increment());
});

# 値を store に保存すべきか常に考える

下記の場合は store で管理するとよい

  • 別のコンポーネントでその値が必要
  • その値から派生した別の値を生成する必要
  • 複数のコンポーネントで同じデータが使用されている
  • タイムトラベルデバッグが必要
  • キャッシュ機能が必要
  • Hot-reloading されたときに値を保持する必要がある

# React-Redux Hooks API を使う

  • connect と比べるとパフォーマンス面で留意点はあるが、それでも hook を使え

# 積極的に多くのコンポーネントを store に接続する

  • その方がパフォーマンスが上がる

# mapDispatch はオブジェクト形式で書け

  • object shorthand のほうが読みやすい
  • 関数形式で書く必要はほぼない

# useSelector は何回かに分けて呼ぶ

  • でかいデータを一発で取得せず、細かく分けて取得する
  • そうすれば再描写の可能性が下がる
  • mapState と異なり、useSelector はオブジェクトを返す必要はない
  • とはいえ、バランスを考えて。コンポーネントが slice 全体のデータを利用する場合は一発で取得しても問題ない。

# 型を使え

  • ミスが減るしドキュメント性も高まるので
  • redux-toolkit は TypeScript に最適化されているのでそっちも使ってね

# Redux DevTools を使え

  • これを使わないなら redux を使う意味も半減よ

# state はプレーンなオブジェクトにする

  • Immutable.js のような特殊なものを使うな

# 推奨

# domain/eventNameの形式でアクションを命名せよ

  • SCREAMING_SNAKE_CASEなどの形式はもはや非推奨

# Flux Standard Action にしたがえ

  • {type, payload, meta, error}の形式

# action creator を使う

  • 一貫性が保たれるため
  • redux-toolkit の createSlice の利用を推奨

# 非同期処理には thunk を使え

  • ほとんどのケースに最適
  • async/awaitで読みやすく書ける
  • saga や observable を使うのは下記をバリバリ使う場合
    • キャンセル
    • デバウンス
    • action の後に action を発出する
    • background-thread な処理を行う

# 複雑なロジックはコンポーネントの外に出す

  • 同期・非同期問わず、複雑な処理はコンポーネントの外(主に thunk、あるいは hook)に外出ししていく

# selector を使う

  • reselectを使って、メモ化された値を取得せよ

# フォームの値を redux で管理するな

  • ほとんどのフォームの値は下記の理由により redux で管理する必要がない
    • グローバルにする必要がない
    • キャッシュする必要がない
    • 複数のコンポーネントで使用しない
    • パフォーマンスが悪化する
  • 少なくとも、編集中の値はローカルで管理し、最終的な値だけ redux で管理するに留める