Kyoto.js 17 デザイナーと考えたAtomic Design
aereal.icon 自己紹介
ブログユーザーチーム
アプリケーションエンジニア、テックリード
上から下までなんでも
新サービスのインフラ構築からフロントエンドまで
アメリカのWebデザイナー Brad Frost氏が提唱したコンポーネント分割のための指針・設計論
小さいコンポーネントを組み合わせてより大きなコンポーネントを作っていく考え方
分子構造に見立てるのでatomic
atoms < morecules < organisms < templates < pagesと大きくなっていく
責務
atoms
デザインの統一性
morecules
行動を阻害しない
organisms
行動を促す
依存関係
下位の概念のみに依存してよい
◯: organisms→atoms, organisms→morecules
×: templates→pages, atoms→organisms
コンポーネント指向とは
アプリケーションの部品をself-containedな粒度でまとめる方針
セマンティクス、プレゼンテーション、インタラクション
これまで: レイヤ指向
セマンティクス: HTML
プレゼンテーション: CSS
インタラクション: JavaScript
「ツイートする」ボタンで考える
code:tweet-button.html
<button class="tweet-button" onClick="doTweet(this); return false;">ツイートする</button>
code:tweet-button.css
.tweet-button { background-color: blue; }
code:tweet-button.js
window.doTweet = () => ...
汎用的なボタンのセマンティクスやプレゼンテーションはうまく配置できるけど…
このセマンティクスとこのプレゼンテーションとこのインタラクションが「ツイートする」ボタンだよ、と紐付ける知識はどこにあるべき?
コンポーネント指向で「ツイートする」ボタンを考える
code:TweetButton.tsx
import styled from 'styled-components'
const Button = styled.button`
background-color: blue;
`;
const doTweet = () => ...
export const TweetButton = () => <Button onClick={doTweet} />;
ひとつのファイルにまとめる
再利用可能にまとめる
キーワード
CSS modules
Web Components
はてなブログ タグでのAtomic Design
はてなブログ タグとは
「はてなブログ タグ」は、幅広いジャンルの“言葉”の意味や、その“言葉”にまつわるネット上の意見に出会うことができる機能です。現在、以下の3つの軸で機能の開発・改善を進めています
意味を知る
意見や感想を知る
同じテーマの記事とつながる
PR: サーバサイドを含めた技術選定の話もあります
https://gyazo.com/d9510791147824b999a315ac3aaeefd4
PR: サーバサイドを含めた技術選定の話もあります
https://gyazo.com/e8220f59a1a3b3270775d74d0e05b2ae
はてなのデザイナーの職能
いわゆるコーダーでもある
CSSを書く、JSXも書く
コンポーネント指向になっていくにつれて、JS (インタラクション) とCSS (プレゼンテーション) の距離が縮まってきた
→ コンポーネント分割の指針や考え方をエンジニアだけが考えれば良いものではなくなり、デザイナーと共通の言語を持つ必要が強くなってきた
はてなブログのフロントエンド変遷
はてなブログでもReactを導入したがコンポーネント指向は徹底していなかった refs.
コンポーネント指向でやっていこうということは決めたが、具体的な規則が欲しくなった
分類の基準
依存関係の制約
やったこと
https://gyazo.com/448b6b1e02b46d9d974cedd717b31740
css-loaderのmodulesも検討したがやめた
styled-componentsでいけそうかデザイナーとPoCを作ったり1週間くらいお試し期間を設けた
Atomic Designの実践 (守)
まずtemplatesやorganismsなど上位の概念にべたっと書いていく
「この部分はこういった行動を促したいからOrganismsにまとめられそう」といったブレイクダウンをしていく
さらにMoreculesやAtomsへ……と繰り返す
Atomic Design原典からの逸脱 (破)
MoreculesとOrganismsの境界が曖昧で悩むことが増えた
ページ数が少ないのでTemplatesとPagesを区別する必要ある?となる
私家版Atomic Designへ至る (離)
Atoms, Organisms, Templatesのみとする
Atoms
サービス内の文脈に強く依存せず、よく知られた機能や意味を持つもの
例: ボタン、バッジ
Organism
ページ内の有機的なまとまり
例: タグ本文、人気記事のリスト
Templates
ページ全体
pagesではないのはあまり強い根拠はなく、Next.jsの規約でpagesが予約されているので混同を防ぐため
依存関係の一方向にする制約はそのまま採用
なぜ私家版に至ったかの振り返り
Atomic Designのような重厚かつ厳格なデザインシステムを必要とするほど大きなサービスではまだない
ページバリエーションは片手で数えられるほど
ではゼロから考えたいかというとそうではない
将来、ページバリエーションが増えてきたときは原典のようにMoreculesなどへ細分化させてスケールさせられる、その時に設計をゼロから見直さずに済む
はてなブログ タグではそれほど有用でなくとも他のサービス開発で経験を活かせるかもしれない、そういった挑戦をする良い機会だった
なぜ私家版に至ったかの振り返り
世の中の事例を見ても原典通りにやっているところは少なく、アレンジしている事例がほとんどだった
Atomic Design振り返り
コンポーネント指向でやっていくとプレゼンテーションとインタラクションの距離が近付いた
世の「フロントエンドエンジニア」は元々こうだったのかもしれない
我が社は分業していた、という文脈があります
完