コンポーネント単位で考えるWeb制作

P R E S E N T A T I O N :

株式会社LIG フロントエンドエンジニア堀祐磨 (ほりでー)

Web制作

コンポーネント単位で考えるWeb制作

自己紹介

LIG INC. Front-end Engineer ほりでー (堀祐磨) 1988年生まれ。多摩美術大学を中退後、デザイナーとしてグラフィックデザイン・Webデザイン・UIデザインを経験。

2015年、株式会社LIGにフロントエンドエンジニアとして入社。

Web制作


概要：

本日のテーマ

Web制作において「コンポーネント」を意識することによって

見積もりや進捗管理、分業など、プロジェクト管理上のメリットがあるビューの構造化をすすめ、開発効率を高める実装上のメリットもある


概要：

本日のテーマ

WebComponentsとは無関係コンポーネントとは画面要素のまとまり

モジュール、ブロックと言い換えても差し支えありません


管理上のメリット ̶̶なぜコンポーネント単位で

考えるのか


実装担当者として聞かれると悩む質問


1ページどれくらいで実装できる?

※本発表の為の便宜的な例であり、実際とは異なります

簡単なコンポーネント (より少ない工数)

複雑なコンポーネント(より多い工数)

トップページチャンネルページ記事ページ

要素がほぼ同じ = 1ページ作れば全部できたも同然

それ以外…1ページづつ順番に完成していく


1ページどれくらいで実装できる? の答え


1ページどれくらいで実装できる? の答え：

×

×

ページ内のコンポーネントがいくつあるか

それぞれのコンポーネントがどれだけ複雑か

サイト全体でコンポーネントがどれくらい共通化されているか


1ページ◯人日で作れたから残りの5ページは◯×5で

完成するはず

だから

と単純に考えるのは大きな間違い


ページを基準にすると変なことに


管理上のメリット̶̶なぜコンポーネント単位で考えるのか

「ページ」を最小の単位として進捗管理を行うと…コンポーネントの数と複雑さで全然工数が違う

ページごとに工数が平均化される訳ではない

次の「ページ」がいつ完成するのか実装担当者以外に予測が立て辛い

あるページは一瞬で完成するのに、あるページは中々完成しない


提案1


コンポーネント単位で計画を立てる

提案1

チャンネルメンバー

プロフィールサイドバー

サイトヘッダー

チャンネルヘッダー

記事一覧フッター

関連記事一覧

記事フッター共有

記事本文


コンポーネントはチケット化しやすい


ページではなくコンポーネントで進捗管理


提案1: コンポーネント単位で計画を立てる

コンポーネントはチケット化しやすい1コンポーネント=1チケット粒度として妥当コンポーネントごとの見積りなら誤差が少ないコンポーネントの依存関係を「関連チケット」で表現できる「あとどのモジュールが完成すればこのページができるのか」を可視化できるコミットログも書きやすい分業しやすくレビューしやすい

Web制作

実装上のメリット ̶̶豊かなデザインを少ないコーディングで


D.R.Y.D.R.Y.D.R.Y.D.R.Y.D.R.Y.D.R.Y.D.R.Y.D.R.Y.D.R.Y.D.R.Y.D.R.Y.D.R.Y.D.R.Y.D.R.Y.D.R.Y.D.R.Y.D.R.Y.D.R.Y.D.R.Y.D.R.Y.D.R.Y.D.R.Y.D.R.Y.D.R.Y.D.R.Y.

Don’t Repeat Yourself

コンポーネントA コンポーネントB

要素◯

要素△

要素☆

要素×

要素△

要素☆

コンポーネントA コンポーネントB

要素◯

要素△

要素☆

要素×

要素△

要素☆

コンポーネントC

コンポーネントCの参照コンポーネントCの参照

別コンポーネントとして分離

参照

参照

別コンポーネントとして分離


HTMLプリプロセッサ


サイトジェネレータや各種テンプレートエンジン

タスクランナー


EJSの場合


<%- include('./_global-navigator.ejs'); %>

_global-navigator.ejs

参照


全く同じ物をまとめても芸がない


ちょっと見た目が違うけど大体一緒のデザイン


サイズやレイアウトが違うだけで要素は同じ



要素がちょっと追加／削除されてる


ベース

要素削減版


色や装飾が違うだけで他は同じ



構造化CSS ～modifier～


構造化CSSにおけるmodifierの概念

.block { /* 基本デザイン */}

.block̶small { /* 小さい版デザイン */ width: 50%; .block__icons { display: none; }}

.block̶news { /* 色違いデザイン */ background: blue;}

<!̶ 基本的な外観 ̶><div class="block"></div> <!̶ 小さい版の外観 ̶><div class="block block̶small"></div><!̶ 色違い版の外観 ̶><div class="block block̶news"></div><!̶ 両方のかけあわせ ̶><div class="block block̶small block̶news">

<!̶ 基本的な外観 ̶><article class="article">

<!̶ 縦レイアウトアレンジ ̶><article class="article article̶vertical">

<!̶ 縦レイアウトアレンジ ̶><!̶ 紫アレンジ ̶><articleclass="article article̶vertical article̶biz">

HTML要素は一緒でclassのみ異なる

※本発表の為の便宜的な例であり、実際とは異なります


include時にどうやってmodifierを変えるか


パーシャルにパラメータを渡す


<%- include('./_article', { modifier:'article—-small' }); %>

_article.ejs

<%- include('./_article'); %>

<article class="article <%= modifier %>"> </article>

パラメータを追加


これだけじゃ上手くいかないパターン

並び順が微妙に違う


似てるけどCSSで吸収しにくい違い


提案2


modifierの概念をHTMLコンポーネントにも拡張

提案2


modifierを条件にif文


<ul class="sns <%= modifier %>"> <li>ツイート</li> <li>シェア</li> <li>いいね!</li> <% if (modifier === 'sns--vertical') { %> <li>Pocket</li> <li>はてブ</li> <li>Google+</li> <% } else { %> <li>はてブ</li> <li>Google+</li> <li>Pocket</li> <% } %></ul>


CSSとHTMLの派生を同じ概念で整理できる!


提案2：modifierの概念をHTMLコンポーネントにも拡張

includeとmodifierによる派生コンポーネントの実装本来構造化CSSの為の概念であるmodifierによって、スタイルの差分とHTML要素の差分を横断的に管理重複がなく、凝集度の高いHTMLとCSS 変更や拡張に強い

ifの中身が肥大化したら、更にファイルを分けて対応 CSSとHTMLを同じ概念で整理できる


HTMLとCSSはセットで管理した方がいい?


提案3


ディレクトリ構造をコンポーネント中心に

提案3

src

sass html

普通は言語ごとに分かれていて、それぞれのルールで構造化を図るが…

_base.scss_header.scss_footer.scss_article.scss

index.htmlarticle.htmlcategory.html

includes

_header.html_footer.html

src

components

site-header

_site-header.scss_site-header.html article-item

_article-item.scss_article-item.htmlarticle-list

_article-list.scss_article-list.html

コンポーネントの中にセットで置いちゃう

pages

index.htmlarticle.html

sass

style.scss@import

include

article-item

_article-item.scss_article-item.html

チケット

コード

コンポーネント

すごく把握しやすい!


提案3：ディレクトリ構造をコンポーネント中心に

コンポーネントを軸にしたソース管理へ

1つのコンポーネント

1つのフォルダ

1つのチケット

1つのCSSファイル

1つのHTMLファイル

すごくスッキリ!


One more thing…


(静的実装だけど) データをビューから分離


写真+リンク+ 肩書き+ SNS+コメント

全部入りコンポーネント

架空のフルバージョンから派生して実体化

modifierとテキスト

ビュー

データ

構造化CSS

_person.ejs

<section class="person <%= modifier %>"> <!-- メンバーコンポーネント —> <h1><%= data.head %></h1> <% if (modifier === 'person—-sidebar') { %>…<% } %> <% if (modifier === 'person—-channel') } %>…<% } %> <% if (modifier === 'person—-small') } %>…<% } %> </section>

<%# データを用意 %><% var arrayData = [ {modifier:’person--sidebar', head:'ナッツ', job:'4代目広報担当・編集長', tw:'...' }, {modifier:'person--channnel', head: 'ヨシキ', job: '漫画編集長', tw: '...'}, {modifier:'person--small', head: 'こやにい', job: 'メディアディレクター', tw: '...'} ]; %> <%# forEachでループ %><% arrayData.forEach(function (record) { %> <% include('./_person', { modifier:record.modifier, data:record } ); %><% }); %>


提案2：modifierの概念をHTMLコンポーネントにも拡張

ビューとデータの分離

コンテンツの量産に最適

文言修正や文言の使い回しが楽動的サイトのビューの設計にも応用可能

まとめ


今日のまとめ

Web制作において「コンポーネント」を意識することによって

見積もりや進捗管理、分業など、プロジェクト管理上のメリットがあるビューの構造化をすすめ、開発効率を高める実装上のメリットもある


今日の

ページの見積りはコンポーネント次第

まとめ

×ページ内のコンポーネントが

いくつあるか

それぞれのコンポーネントがどれだけ複雑か

サイト全体でコンポーネントがどれくらい共通化されているか

×


今日の

提案1：コンポーネント単位で計画を立てる

まとめ


今日の

重複を解消するinclude

まとめ


今日の

構造化CSSのmodifier

まとめ


今日の

提案2：modifierの概念を HTMLコンポーネントにも拡張

まとめ


今日の

提案3：ディレクトリ構造をコンポーネント中心に

まとめ


今日の

One more thing…データをビューから分離

まとめ


今後の展開


今後の展開：

今後の展開

WebpackでJavaScriptもパーシャル化コンポーネント単位でテスト

Yeoman


コンポーネント化で、Life is Good な制作を!

Thank you!

http://qiita.com/y_hokkey株式会社LIG フロントエンドエンジニア堀祐磨 (ほりでー)

http://qiita.com/y_hokkey

Software

コンポーネント単位で考えるWeb制作