コンポーネント指向とは？走り書き

画面の構成要素、部品
ボタン、ラベル、アイコン等々....

画面の構成要素を意味のある単位に分割して、画面を構築すること

AtomicDesign

画面の要素を5分類に分ける手法

• atoms
• molecules
• organisms
• templates
• pages

一番の大きな分け方はドメイン知識を有しているか？

ドメイン知識を有しているとは？

端的に表すと、そのサイトでしか使えない知識を持っているということ

例）ツイッターWebのサイドメニュー

別のサイトでは使えないのでドメイン知識を有していると考えられる

organism

ボタン、アイコン、フォームなど

どのサイトでも汎用的に使用することが可能なコンポーネント

可能な限り最小単位で分離していくとよい

各ページで使い回すと良い

ここをブラッシュアップしていくとデザインシステムになる

atom,molecule

前項にも挙げたがドメイン知識を有していないコンポーネントに注力すべき

このコンポネートを組み合わせることでドメイン知識を有したコンポーネントを作成する

ドメイン知識を有していないコンポーネントを各ページで使い回し、例外を許さないことがデザインを加速させる

なにをどの単位でドメイン知識を有していないとするかの設計が肝となる

コンポーネント指向において隙間はどこに持たせるべきか

階層構造となっているコンポーネントにおいて、隙間は
親、またはどちらの持ち物ではない

a画面ではボタンにmargin leftが16px必要であったため、ボタンコンポーネントに指定した

b画面ではmarginは必要なかったので、cssをオーバーライドしてmarginを打ち消して使用した

コンポーネント指向において、上記は間違い

この場合marginは使用する側=親画面でmarginを持つべき

隙間もまたひとつのコンポーネントとして考えることもできる

paddingに関してはコンポーネントで持って良い

最近atomic designのディレクトリ構造が廃れてきている傾向がある気がする

atomとmoleculesを分ける意味がない
各階層ごとに名前に意味を持っていないので
プロジェクトごとのルールによってブレが生じるなど

ui
atom,molecule
ドメイン知識を有さない独立した単位のコンポーネント
uiライブラリとして機能し、他プロジェクトでも使い回すことができる
ui内部で依存関係を持つことができる

domain
organisms
ドメイン知識を有しているコンポーネント
そのサイトのみで使用される
uiにのみ依存することができる
cssで特定のコンポーネントのスタイルを変更するのは不可、fontsize,colorなど

page
template,page
1ページを成立させる単位
presentational(表示のみ)とcontainer(ロジック、APIへの依存)に分かれる

functional
該当なし
実態、表示を持たないコンポーネント
メタ情報、エラーハンドリングなど

UIのディレクトリの分け方とfigmaのコンポーネントの単位は揃えたほうがいい

figmaがリンクしていることがデザインシステムにつながる

世の中的にコンポーネントはこうわけるべきだというデファクトはまだない

デザイナーとエンジニアで合意した共通した認識を持つことが大事