Open1
【学び】フロントエンドのコンポーネント設計
試験的運用。
このスクラップは、以下の記事を読んで学んだことをアウトプットするためのものです。
学び
■ コンポーネント志向
- アプリケーション開発において、分割した部品(コンポーネント)を組み合わせて開発する考え方
-
分割統治法(大きな課題を小さく分割することで課題解決をしていくという考え方)や、単一責任の原則(関数やクラスなどの"モジュール"が持つ責務は一つにすべきという考え方)などがベースに含まれている
- → ひとつのコンポーネントは理想的にはひとつのことだけをするべき
■ コンポーネント設計で意識すること
-
コンポーネントの責務を明確にする
- 1 つのコンポーネントが、通信、ロジック、UI など複数の責務を持っていると、再利用性がないコンポーネントになってしまう
- 【📝筆者メモ】最近は、UIを担う各コンポーネントの中でそのコンポーネントに必要なデータ取得のリクエストまでまとめて行なってしまうのがトレンドになっているとのこと。以前は最上位コンポーネント(Pageコンポーネント等)で外部APIから値の取得を行ない、その値をpropsバケツリレーで目的のコンポーネントまで送り届けるというような方法が主流だったが、React QueryやuseSWRなどの登場によって、各コンポーネント自身がuseSWRなどを用いて自身に必要なデータを自分自身で取りに行くことが可能となった(UIとデータ取得の統合)。この変化によってよりコンポーネント間の結合度合いを疎結合とすることが可能になっている。
-
コンポーネント設計はデザイナーとの協働作業
- モックを作る時点からコンポーネント設計は始まっている(コンポーネント化する単位やデザインルールなど)
■ ディレクトリ構成
ここは他の色々な記事も参考にしつつ別スクラップとしてまとめた方がいいかも(書く際の参考記事は以下の通り)
- SPA Componentの推しディレクトリ構成について語る
- 私の推しフロントエンドディレクトリ構成と気をつけたいポイント
- 私のフロントエンドディレクトリ構成・テスト観点 2022
- Next.jsディレクトリ構成・設計再考(featuresが何を解決するか)
[MEMO]
・最小コンポーネントは「ロジックを持たない」コンポーネント(他のコンポーネントに依存しない)
・最小コンポーネントを組み合わせて、ロジックを持つコンポーネントを作る(他のコンポーネントに依存する)。ここではデータ取得はあまり行わないイメージ。どんなデータを表示するかはこの親がpropsを用いて決める感じ。?
・外部APIからのデータの取得は上記よりも上位のコンポーネントで行なうことが多いが、前述の「各コンポーネントごとにUI+データ取得をする」のがトレンドらしい今、上位コンポーネントからデータを落とすのをどこまで使うかはわからない。ただ後で気づいたが、上のコンポーネントは形式さえ決まっていればどんなデータが来てもそのデータに応じて表示を切り替えられるので、「UI+データ取得」はどの粒度・階層のコンポーネントにあたるのかはもう少し検討しないとダメそう。著者の記事内にある、コンポーネントごとの責務早見表がわかりやすくてよい。自分でも作ってみたい。
・