AtomicDesign指針 - nnnaoki1998/spocon GitHub Wiki

コンポーネント分類

Atoms

  • これ以上分けられない単位
  • 特定のプロダクトについての知識を持たない
  • ex. ボタン、テキストフィールド、セレクトフィールドなど

[Q]セレクトフィールドは複数のMUIの構成要素で表現されるが、atomsで管理する?

実際のセレクトフィールドのコンポーネント

export const SpoconSelectField = <T,>({
  selectFieldId,
  labelId,
  label,
  selectionItems,
  getSelectionItemKey,
  getSlectionItemName,
  value,
  onChange,
}: Props<T>) => (
  <FormControl fullWidth>
    <InputLabel id={labelId}>{label}</InputLabel>
    <Select
      labelId={labelId}
      id={selectFieldId}
      value={value}
      label={label}
      onChange={onChange}
      sx={{ width: '100%' }}
    >
      {selectionItems?.map((item) => (
        <MenuItem
          key={getSelectionItemKey(item)}
          value={getSlectionItemName(item)}
        >
          {getSlectionItemName(item)}
        </MenuItem>
      ))}
    </Select>
  </FormControl>
);

[A] atoms配下で管理する

  • 実装に引きずられて管理する場所を決めるのではなく、その部品自体に着目(UI視点)して管理場所を決める
    • もしMUIの構成要素を複数持つことからMoleculesで管理するようにした場合、開発者は実装を知っていないとセレクトフィールドのパーツを見つけるのが難しくなる
    • またMUIではなく他のデザインフレームワークを使用して1つの構成要素でセレクトフィールドを表現できた場合、ディレクトリを移動させるのか?->その場合import文にも変更が入り、影響範囲が大きくなる
    • そのため実装ベースではなく、部品がどのAtomicDesignのコンポーネントの制約を満たしているかをもとに検討する

Molecules

  • Atoms を複数個使った再利用性のあるコンポーネント
  • 特定のプロダクトについての知識を持たない
  • ex. 入力フォーム(ラベル+テキストフィールド)、セレクトフォーム(ラベル+セレクトフィールド)

Organisms

  • Atoms、Molecules、他のOrganismsを組み合わせて1つの明らかな機能を持つコンポーネント
  • 特定のプロダクトについての知識を持つ
  • 必要なデータを取得して、Atoms、Molecules、他のOrganismsに渡す
  • ex. チーム情報入力欄(チーム編集画面、チーム登録画面)、ヘッダー、サイドバー

Templates

  • 複数のOrganismsからページ全体(ヘッダー、フッター含む)の枠組みを構成するコンポーネント
  • レイアウトやコンポーネントの配置に焦点を当てる
  • ページに必要なOrganismsを呼び出して、デザインを整える役割
  • レイアウトが一緒の場合は1つのTemplateを複数Pagesで共有してもOK(チーム登録画面と編集画面のような) => 2つの画面で同じレイアウトを共有して、常に同じデザインを保つ
  • ex. Header, Footer, Sidebar, MainContentAreaなどのOrganismsを含むページの骨組み

Pages

  • ページのエンドポイントになるコンポーネント
  • 基本的に1画面に1つのPageが紐づく
  • ページで必要なデータを取得して下位コンポーネントに渡す
  • ex. Templatesを囲むタグとTemplatesに必要なデータを渡す骨組み

ロジックを呼び出すコンポーネント

各コンポーネントの責務を分離してコンポーネントの再利用性を高めるため、Atoms、Molecules、Templatesにはロジックは書かず、Pages、Organismsにロジックを持つように実装する。

Atoms, Molecules, Templates はレイアウトとしてのまとまり、Organisms と Pages はコンテンツベースでのまとまりとする。 Atoms, Molecules, Templates はユーザーインターフェースや、親コンポーネントから渡されたデータをどう表示するかに専念する。 Organisms と Pages はコンテンツに関心が高い。API や store などデータの取得・変更の責務を持つ。

各コンポーネント配下のファイルの命名規則

名前をできるだけ統一するために一旦作成しましたが、他の名前がよさそうであれば随時変更していきたいです!なにか良い案あればお願いします!
一旦↓で進めます。

※Atoms、Moleculesは他のいい名前があれば変更してもよさそう
※他の名前が適している場合は以下に沿わなくてもOK。(Organismsのヘッダーは〇〇Barとするなど)

Atoms

  • Spocon〇〇
  • 役割としては特定のプロダクトの知識を持たないが、汎用的な名前にするとMUIのコンポーネント名と被りエラーになるため、Spoconを先頭につける

Molecules

  • Spocon〇〇
  • 役割としては特定のプロダクトの知識を持たないが、汎用的な名前にするとMUIのコンポーネント名と被りエラーになるため、Spoconを先頭につける

Organisms

  • 〇〇View
  • 役割として明らかに一つのUIとして成り立つため、末尾をViewとする

Templates

  • 〇〇Frame
  • 役割としては枠組みのデザインとなるワイヤーフレームのようなもののため、末尾をFrameとする

Pages

  • ページの名称(ex. TeamProfileEdit)
  • 基本的に1ページに1Pagesができるため

参考記事

⚠️ **GitHub.com Fallback** ⚠️