atomic design 再入門覚書

こじこじ

コンポーネントの props にスタイルをオーバーライドさせる余地を残しておくのも場合によってはありかも
- classNameを追加で受け取れるようにするのはCSSの記述順が保証されないため確実にオーバーライドするためには important の利用が避けられない
- Iconなどの Atoms にはwidth, height のプロパティをつければサイズ違いもカバーできる
  - 今まで background-image でやっていたためサイズ違いはCSS修正が必要になってしまい微妙だった・・（もしくは、ラップする親コンポーネントの要素で調整が必要→divが増える
- デザインガイドラインがかっちり決まっているようなケースではオーバーライドの余地を残す必要はおそらくなくなる。が、大抵はそうはいかない

こじこじ

balloon などの吹き出し表示位置の調整なども style 属性を props として渡して制御できるようになるのが良さそう・・・（これも親側の要素で指定していたのでdivが増えていた）

こじこじ

balloon に関しては、表示する内容を明示的な props ではなく children で受け取ると、アイコンなども内包できるようになる
- 特に具体的な理由もなく children を無闇に使うとあまり良くないイメージがあった（無秩序にならないか）が、使い方次第か
- 例えばボタンコンポーネントにおいて、開発途中でテキストが2行かつそれぞれの行の font-size が異なるデザインが出てきたりする
  - ボタンコンポーネントにはデフォルトのfont-sizeを指定しておきつつ、上記のようなデザインに対応する場合は children に CSS クラスを指定したタグを含め、スタイルを別途当てるようにする？（その場合はボタンコンポーネントを内包する親要素でスタイル指定？
  - でも個人的にこれはなんとなく気持ち悪さを感じてしまう・・？

こじこじ

ロジックと表示に関する責務は分ける
- Container コンポーネントと Presentational コンポーネント
- 互いに関与しないことでそれぞれの変更に強くなる
- バリエーション違いの Presentational を増やしやすい
  - Iconコンポーネントの例
  - IconFactory を噛ませて簡単にバリエーション増やす
  - コンテナは共通

import React from 'react';
import styles from './styles.css';

export const IconPresenter = ({
  iconName,
  height = 20,
  width = 20,
  ...props
}) => (
  <img
    src={`/icons/${ iconName }.svg`}
    alt=''
    height={ height }
    width={ width }
    { ...props }
  />
)

export const IconContainer = ({
  presenter,
  onClick,
  className = "",
  ...props
}) => {
  if (onClick) className += `${ styles.clickable}`;
  return presenter({ onClick, className, ...props})
}

export const iconFactory = iconName => props => (
  <IconContainer
    presenter={ presenterProps => <IconPresenter {...presenterProps} />}
    { ...{iconName, ...props}}
    />
)

export const TrashCanIcon = iconFactory('trash-can');
export const ChevronRightIcon = iconFactory('chevron-right');
export const SearchIcon = iconFactory('search');
export const SettingsIcon = iconFactory('settings');

こじこじ

プレゼンテーショナルからロジックを分離すれば、デザイナーなどの非エンジニアも安心してコードを変更できる
- 職域ごとの関心も分離できる→開発フローがスムーズに