Zenn
Open5

普段コンポーネントを作るときに意識していることをまとめる

koukou

あとで分類分けしたりより詳細に書いたりする

  • 基本方針、そのコンポーネントに関わることはそのコンポーネントの周辺を探せば済むようにしたい（コロケーション）
  • 基本的にコンポーネントはUI責務に特化させるのが見やすくて好き
  • コンポーネント内のロジックは安易にカスタムフックや関数に切り出す
    • この時の切る場所が悩みどころ。コロケーションが好きなので、近くに切り出すことを意識している
  • カスタムフックから返すオブジェクトや関数はメモ化して返す
    • 再レンダリングの抑制判断は使う側に任せる。フックからはやることやってるよという状態で返す（uhyoさん記事参照）
    • よしこさんが言っていたように、ここをリンターとかで縛れるとなお良き
  • コンポーネントがイベントハンドラを受け取る場合は、on~で受け取り、handle~で渡すように意識する
    • learn nextのReactのやつにも軽い説明あった
    • ちなみに語順は、on〇〇Click、handle〇〇Clickが綺麗。ただ、〇〇が長くなりすぎると分かりづらいので注意。また、onClick〇〇だとClickが動詞みたいに個人的に見えて気持ち悪い。
  • コンポーネントのメモ化（React.memo）はあまり意識していないが、基本付けるという方針でもいいのでは？という気がしないでもない。
    • memoする際に生じるオーバーヘッドの記事とかあった気がするのでまたそれ読んでおく
  • コンポーネントはアロー関数式で作り、型はFCで付ける
    • 関数宣言の形式だとmemo化や、forwardRefする際に形を関数式に変える必要が出てくる（確か）。だったら初めから関数式の形の方がいい
    • テンプレ作って強制
  • 状態を扱う際カスタムフックを作る際、setStateをそのまま外出しすることはせず、目的に応じた関数でラップして、それを外部へ公開する（ある種カプセル化？）
    • オブジェクト指向の無闇にセッターを公開しないと同義
  • 関係性が比較的強いものであれば、割とライトに同じコンポーネントファイルにexportつけないprivateなコンポーネントとして切り出すことも多い
    • クラスで、publicメソッド内からある一連の処理をprivateメソッドに切り分ける感覚
  • レイアウトは外側・親側・使う側のコンポーネントが担う（マージンは外ってやつ）
  • 子側・使われる側は、どのように使われるかを意識しない（レイアウトに口出さない）
  • 切り出したフックの命名は、「use機能名」を意識する。使う側から見た時に「〇〇という機能の利用を宣言する」という意味合いで使えているか。基本useの後は名詞になる。
    • ex. useStateは、「"状態"という機能の利用を宣言」というメンタルモデル。
koukou

観点

そもそもコンポーネントとはなんぞや。

コンポーネントにはおそらく「レイアウトを規定するコンポーネント」と「UIを規定するコンポーネント」がある。

「レイアウトを規定するコンポーネント」は「〇〇Layout」と命名されるようなものだけではなく、「〇〇Header」のようなものもこちらに属する気がする。

このとき、今回「コンポーネントを作る時に意識していること」といったときのコンポーネントは、後者のUIを規定するコンポーネントのことを主に言っているのではないかと思った。

koukou

観点

  • 機能追加・削除等の変更・改修が容易であること
  • (テストが書きやすいこと)
    • コンポーネント単位のテストの旨味がまだあまり分かっていないので微妙
koukou

「コンポーネント設計」とタイトルに入れて本を書く。

まず「コンポーネント設計」という際の「コンポーネント」が何を指すのかを定義する。
レイアウトを規定するのではないコンポーネントのこと。UIを責務とする。

その後、テーマを細分化して小さく書いていく（コンポーネント分割、スタイリング、テストなど）。
これらのテーマが相互に絡み合うこともあるかもしれないね。