イベント概要
- 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分は流石に短かった。