フロントエンドの設計で考えることをざっくりとまとめた話

フロントエンドで設計を考えてることを雑に言語化。 要件に応じた設計を考えるとき、個人的に再利用性と依存関係から設計を考えることが多い。 (書き込み要件が多い場合を除く)

再利用性

  1. コンポーネントの再利用性
  2. データ構造の再利用性
  3. データロジックの再利用性
  4. データの再利用性

依存関係 （今回割愛）

  • コンポーネントが、状態管理や外部へのリクエストをどこまで依存を許可するか

再利用性を考えるのに、それぞれの分散が一般的かを考えてレイヤー分けを考える

1. コンポーネントの場合、

  • 分散の高いコンポーネントが多いかどうか
    • 分散とは、ページをまたがって使われているかどうか。以下、例
      • セレクト便のあるコンポーネントは、Top画面やセレクト便画面で使われている
      • 商品のとあるコンポーネントは、Top画面やカート画面で使われている
      • ユーザアカウントに属するコンポーネントは、Top画面や、マイページ画面で使われている
  • レイヤーの判断
    • 分散の高いドメインコンポーネントが3つ以上存在する → どのページからアクセスできるところにドメインコンポーネントを置けるようにする

2. データ構造の再利用性を考える場合

  • コンポーネントの場合と同様、3つ以上の画面で使われている & コンポーネントに依存せずに使われている
  • レイヤーの判断
    • 複数の画面で使われている & コンポーネントに依存せずに使われている → models ディレクトリの作成
    • コンポーネント依存 → コンポーネントに書く
  • コンポーネントに依存せずが、重要。大抵は、コンポーネントに依存したロジック
  • vitanote-jpでは、modelsディレクトリを作っていない。

3. データロジックを考える場合は、データ構造と同様

  • レイヤーの判断
    • 3つの画面で使われている & コンポーネントに依存せずに使われている → hooksディレクトリを作成
    • コンポーネント依存 → コンポーネントに書く

4. データの再利用性

  • 状態管理やキャッシュの話
  • コンポーネントの場合と同様、3つの画面で使われているかどうか
    • 一度取得した生のデータをどれぐらい使い回すか、
    • 一度取得したデータの編集ロジックをどれぐらい使うか、
  • Redux Flow で考えるとわかりやすい??
  • レイヤーの判断
    • 一度取得した生のデータを3つ以上の画面で使う → storeレイヤーを追加し、global storeとしてデータに保存
    • 一度取得した生のデータを2つの画面で使う → contextレイヤーを追加し、useContextなどを利用する
    • 一度取得したデータの編集ロジック を 3つ以上画面で使う → selector のレイヤーを入れれ、取得したデータを整理する