CodeGridさんの記事をまとめてみました。
いまどきのコンポーネント設計をめぐる座談会

コンポーネントとは

Vue.js、React、Angularなど主にWebアプリケーション開発でページを構成する各部品のことを指す。

コンポーネント感の相違って！？

見た目のコンポーネント
データの流れに注目したコンポーネント

見た目のコンポーネントとは

デザインの見た目でコンポーネントを切ったもの

データの流れに注目したコンポーネントとは

大きなオブジェクトをひとつのコンポーネントにした場合、そのコンポーネントは全部のAPIを叩かないといけない。
小さなコンポーネントを複数含むコンポーネント設計すれば、大きなコンポーネントで取得したデータを小さなコンポーネントに流してあればいい。そうすると小さなコンポーネントはもらったデータの処理だけをすればよくなる。
その全体のデータの流れを考えた上でコンポーネントを切ったもの

コンポーネントを作るときに苦労したところ

見た目のコンポーネントに依存してつくったら、大きすぎてデバッグがしにくかった。
でっかいテーブル（表）をひとつのコンポーネントにしたら、そのテーブルに流されていたデータが膨大になってしまったので、1列ずつデバッグできるように設計すべきだった。(変更するには大手術)

開発するときの注意点

HTML/CSSが先か、JSが先か

jsを書くエンジニアがコンポーネントを切ってから、HTML/CSSの作業をした方が効率的なときがある。
jsとHTML/CSSどちらかの作業が終わってからの作業の場合、「cssを今から直すのはつらい」「jsのデータの持ち方を変えたい」などの出戻りが発生

cssの書き方が従来とは違う!？

コンポーネントごとにスタイルを書いていく。
そこに書いたものはほかのコンポーネントに影響しないし、使い回しもしない。
同じボタンであっても、コンポーネントが違えば、それはそれ。
使われているかどうか判断できないものが増えていくのを避けるのが目的

CSS in JSを使う

CSS in JSとはJSでスタイルを当てること。
CSSをそのまま書いて読み込んでいると、どこに干渉するかわからないので使う。
そこにしかスタイルを当てないというのを実装でなんとか実現しようとしたのが、CSS in JS。
↓
フレームワークに依存するので2、3年後にはレガシーになって管理が難しくなる可能性あり

従来の書きがやっぱり良い

外部cssファイルを読み込んでモジュールごとにスタイルして流用、継承した方が効率的。

結論(？)

ページレイアウトのベースとなるスタイルは外部cssで書き、コンポーネント単体でのスタイルはコンポーネントごとで書いていく。

※プロジェクトによりけり(?)

作業者全員が共通認識を持つことが大事

デザイナー、マークアップエンジニア、フロントエンドエンジニアの3者がコンポーネントの単位を理解していると開発が進む。
コンポーネント思考っていうのをエンジニア側は持っている。
かたや、デザイナーはビジュアルデザインとして物事を見ている。

ワークショップを行うことで3者の認識のすり合わせができる。

コンポーネントの粒度をお互い意識するために3者でワークショップを行う。

例) 完成した画面を紙に出力して、ハサミを持って「コンポーネントってどこですかね？」と確認。そこで切った理由をお互いに説明し合う。
↓
エンジニアが、これは確かにこういう見た目だけど、この下の部分は同じデータカラムに入っていて、データベース上はここはセットだし、持ち運びやすさも考えると、これをセットにするほうがいいんですよっていう話をする。

するとデザイナーはそれを知らないだけだったので、じゃあ、それを元にコンポーネント再設計してみますねという話になって、前へ進む。

UIはデザイナーだけの作業ではない。

コンポーネント設計を推し進めるとUIはデザイナーだけの作業ではなく、エンジニアもUIを意識する必要が出てくる。
UIはプロジェクトメンバー全員でつくっていくものである。