More than 3 years have passed since last update.

Atomic Designを実現するコンポーネント指向開発のいま

Last updated at 2020-01-21Posted at 2019-03-25

イベント概要

https://base.connpass.com/event/122517/
2019/03/20(水) 20:00 〜 21:30
会場：hoops link tokyo（東京都渋谷区宇田川町28-4 三井住友銀行渋谷西ビル6階）
ハッシュタグ：#atomic_shibuya

次の5年を支えるVue.js製UIコンポーネントライブラリを育てる

スライド：https://speakerdeck.com/simezi9/build-up-vue-dot-js-component-library-for-next-five-years

なぜコンポーネントライブラリを作ったのか

ミッション：価値の交換をよりシンプルにし、世界中の人々が最適な経済活動を行えるようにする

ネットショップ作成サービス・ショッピングアプリ「BASE」

裏側の実装

サービスインから継ぎ足し続けられたコード
場当たり的な実装が多くメンテナンスが難しい
デザインクオリティの維持が難しい
社内のデザインガイドラインがない

次世代管理画面プロジェクトスタート

次の5年間の開発を支える

メイン機能となる管理画面の全面リニューアル
コンポーネントライブラリ作成によるデザインの統一

BASEの管理画面に求められるもの

70万ショップのオーナー
「お母さんも使える」コンセプト

サイト全体でデザインのクオリティを維持するためにコンポーネント化して一元管理したい

→ コンポーネントライブラリ「BBQ」登場

構築したライブラリと作業フロー

ライブラリ

Vue.js, TypeScript + Storybook
使い回せるように独立したリポジトリ
- ユーザーはVueのプラグインとして利用できる
Atomicデザインを取り入れた設計 ← 追求はしてない
- サイト上で3回以上使うものを使う = 再利用性の高いものだけ
- Atoms + Moleculesを登録
- 厳密なレイヤー分けはしない
  - AtomとAtoｍを組み合わせたもの、程度の感覚

storybook上で確認できること

storybookを見るだけで実装ができる状態

実際に動くコンポーネントを作れる
コンポーネントを組み込むコードが見える
コンポーネントに渡すプロパティの確認ができる
プロパティを調整しながら、コンポーネントの動きを確認できる

作業フロー

Sketchでコンポーネント作成
GitHub issueでコンポーネントの変更を登録
プルリクでコンポーネントの実装＋Readme.mdの更新
PRごとにデプロイされたstorybookで動作確認
マージ & デプロイ

重要なこと

デザイナー：Sketch フォトショで完結したい
エンジニア：JavaScriptの世界で完結したい
コミュニケーションする場所が必要

（エンジニアから見た）あるある

知らない間にデザインの調整がSketch上には入っているのに、エンジニアが気づかないので実装されない
表面的なデザインの裏に隠された意図がわからない
- 色の使い方、モーダルとダイアログの使い分け etc

ひとまずはGitHubを協業の場所として整理している

協業の場としてのGithub

issueとして案件を起票する
変更の差分はGitHubに集中させる
- sketchをエンジニアが見て変更をキャッチするのは難しい
- 知らないうちに仕様が変わったのに気づかない問題を避ける
コンポーネントの概要はReadme.mdに
- StorybookからもReadme.mdをimportして同じものが見えるように
- コンポーネントごとにReadmeを用意することで、PR上で仕様のドキュメントと実装のコンポーネントごとの差分を同時にレビューすることができる（仕様と実装のズレを防止）
- 誰でも編集しやすく、心理的負荷の低いReadme.md

テスト

Jestを採用
@storybook/storyshotsによるDOMのスナップショットテスト
- storybookに登録してあるコンポーネントすべてをDOMで比較してdiffを出してくれる
@storybook/storyshots/puppeteerによるスクリーンショットのビジュアルリグレッションテスト
- storybookに登録してあるコンポーネントすべてを自動で撮影してdiffを比較してくれる
  - ※ブラウザの動作で、実行タイミングの問題などでやや安定性に欠けるので全部お任せはまだ難しい
storybookを更新していればテストも自動で行える安心感

→ 次世代管理画面第一弾リリース

実際にやってみてどうだったか

ライブラリ作成の進め方

小さいコンポーネントから順番に作り完成度を高める
- 例：ボタン、インプットなど
storybook上で動いているように見えても、実際に組み込むと、絶対に次々と問題が出てくる
なので、土台をしっかり固める（小さい問題から潰す）
張り切って、すべてのコンポーネントを最初に出し切ろうとしない
- 絵に描いた餅になりがち
実際のアプリケーションに組み込みながら開発する
- コンポーネントの開発だけを独立したメンバー・プロジェクトで進めても、コミュニケーションコストや手戻りばかり増えて上手くいかない

小さいコンポーネントづくりなら簡単？

小さい部品でも一定の知識・能力が必要
- 標準のHTMLをラップするには、HTMLの仕様を知らないといけない

例えばそのatomコンポーネント…

標準のHTMLと同じ感覚で伝えるインターフェイスになってますか？
- changeイベントしか発火しないinput（inputイベントが来ない）
- mouseenterなどが発火しない
- disabled属性を渡しても無反応
使う時にスタイルの微調整はできますか？
- z-indesを内部で設定している
- marginが設定されていて、余白を直せない
アクセシビリティ対応は適切にされていますか？

Vueとコンポーネント設計

コンポーネント設計・実装はやるとイメージ以上に難しい
Vue.jsは最初の一歩を踏み出しやすいフレームワーク ≠ 必要になる知識・技量が少ない
実装する前に、VuetifyやMaterial-UIなどOSSライブラリのソースを見て雰囲気を掴むのをオススメ
メンバーの習熟度が高くない場合には、おそらくいきなりコンポーネントとかを考えずに、まずはVue.jsで一通りコードを書いて経験を積む方がよさそう

最初に用意しておきたいこと

コンポーネントは小さい修正を頻繁にリリースする
- ビルド・リリース周りは最初から作り込む価値がある
  - なるべくリリースの不可を下げておく
後で何かをしようとするとWebpackが超辛い

最初にやっておくといいこと

linter/prettierの整備
Storybookの整備＋必須に近いプラグインの導入
- @storybook/addon-actions
- storybook-addon-vue-info
- @storybook/addon-knobs
- @storybook/storyshots
（必要なら）TypeScriptの導入
PR単位でのstorybookの自動ビルド

まとめ

コンポーネント設計して要件を整理すると、初期コストは確実に上がる
- 仕様決定のコスト
- エンジニア・デザイナー間のコミュニケーションコスト
長期的に使うコンポーネントを別ライブラリに切り出すのは有効
routerやstoreなど、具体性の高いコンテキストが入ってこないので、コンポーネントをクリーンに保てる
いきなりコンポーネントを作ろうとせず、まずVue.jsに慣れる
WebpackやJestがエラーになっても泣かない

おまけ

ワイドディスプレイはChrome Devツールが開きやすいので良いぞ
テックブログ: https://devblog.thebase.in/
オウンドメディア: https://basebook.binc.jp/

質問

ライブラリの開発期間は？
実案件と並行してやってる（1年〜2年の期間）
形になった段階は3〜４ヶ月
ボイラープレートは使わなかった？
プロジェクトに途中から入ったので、Vue CLIは使わなかった
振り返ると最初からVue CLIでよかったと思う
社内のフロントエンド情報のインプットはどうやった？
社内でブートキャンプを開いてやった。

人生がときめくUIコンポーネント片づけの魔法

スライド：https://speakerdeck.com/yumihsiao/ren-sheng-katokimekuuikonhonentopian-tukefalsemo-fa

精神論でいきます。

おおよそ、人生がときめく片付けの魔法の内容に沿ったもの

片付けでやるべきことは2つしかない

モノを捨てる
収納する

物を捨てる前に収納の技に走ってはいけない。
収納法の厄介なところは、ものを中に収めると一見問題が解決したように見える。

ものを減らさないまま、収納のことをあれこれ考えたり、収納の技に走り始めたところで意味がない。

捨てる技

捨てる前に具体的に理想を妄想してみる
なぜそうしたいのかを突き詰めていく
心がときめくものだけを残す
後は全部思い切って手放す

ときめく？

客観的。
- ユーザーテスト
- ABテスト
- ユーザビリティ
- メンテナンス
主観的・感情的
どれだけユーザーを揺り動かせるか
サービス世界観・人格
作り手の愛情（良いコンポーネントである）

使えないColor Systemを捨てましょう

本当に使いたい色はそんなに多くない。

Bootstrap
bulma
- 本当に使いたい色はそんなにありますか？
- 本当に使いたい色は
- Primary
- Secondary
- ContentColor
- SubContent

膨大なGridSystemを捨てましょう

代わりに、コンテンツを基準にしたブレークポイント

CSSフレームワークを捨てましょう

CSSフレームワーク＝いつか使うかもしれないの集合
代わりに、ちゃんとしたreset.css, modernizr.js

CSSの書き順

block -> element -> element-modifier

どうしても捨てられない

過去に対する執着と未来に対する不安
これだけのものを持っていれば問題なく暮らせる
ものがなくてもなんとかなる、モノがなくても行動すればだいたい解決する
判断の責任を人に委ねない
片付ける・捨てることは、自分の価値観で判断していく経験の連鎖
判断を積み重ねることで経験が積まれていく
大量の使わないコンポーネントに時間をかけるよりは「本当にときめくもの」に大いに時間と情熱を注ぎましょう！

ユーザーが感覚的に使えるサービスを目指す "一休.com レストラン" コンポーネント指向開発の今

スライド：https://speakerdeck.com/japboy/component-based-design-for-ikyu-users

コンポーネント

データ・テンプレ、ロジック、スタイル、それぞれ関連性が深いものをモジュール化
ファイルタイプによる縦割りではなく、関連性によるファイルタイプ横断

すべてをコンポーネントとして捉えると

プログラムとしての粒度
グローバル
UI
グローバルデータ
フィルター
グローバルスタイル
UI

適切にレイヤー化できるやつないかな

ITCSS → 逆三角形で提示

ITCSSの分け方

Settings：CSS変数
Tools：ミックスイン、フィルター
Generic：グローバル
Elements：Atoms
Objects：Molcules
Components：Organisms
Trumps：例外レイヤー

ITCSSとAtomicDesignとの対比

ITCSSだと、Atomsレイヤーに当たる抽象度を細かく分類できそう。

ITCSS	AtomicDesign
Settings	Atoms
Tools	Atoms
Generic	Atoms
Elements	Atoms
Objects	Molcules
Components	Organisms
Trumps

改善結果

早くはなった。
コンバージョンは上がらなかった。KPIには寄与しなかった。

大事なこと＝ユーザーファースト

再利用性、生産性の向上、スコープ管理
サービスとユーザーの対話インターフェース
継続的なユーザビリティ改善の基盤を獲得した

重要なのは、Atomic Design MethodologyやITCSSの持つメンタルモデル

メソッドに乗っかればうまく分類できるわけではない

ITCSSだと、Atomsレイヤーに当たる抽象度を細かく分類できそう
Trumpsは開発途上の洗練されてないコンポーネント置き場としても有用
ITCSSのレイヤー名やレイヤー拡張はユーザー側で再定義

重要なのは、チームに必要なものの合意を取ること

一時期

デザイナー一人しかいない状態になった
一休のデザインの言語化

ベースライン

カラースキーム
タイポグラフィ
インターフェースデザイン ← 共通のボタンデザインを定義したい
グリッドシステム

→ デザイナーの意思決定をガイド化

ボタンをどうコンポーネント化するのか

役割ごと？
サイズはどう定義するのか？
絶対値の場合マージン変わるしどうするの？
グリッドデザインだと、同じ割合で表示できる

所感

コンポーネント化とか頑張りたかったら、今日発表した会社に転職するといいと思う。
思考停止でCSSフレームワークをドカドカ入れていくと、後から捨てにくいので、ちゃんと議論して必要なものを考えていれることも重要だなと思った。
AtomicDesignのAtomのスコープ広すぎ問題
下手にコンポーネント化をするより、まずVue.jsに慣れる方が先だと思った。
懇親会30分は流石に短かった。