InsideFrontEnd 参加レポート1(コンポーネント化って？)

InsideFrontEnd 参加レポート(コンポーネント化って？)

はじめに。

2017/02/25に開催されたInsideFrontEndの参加レポートになります。
今回、このイベントに参加するにあたり、ブロク書く枠、という形で参加してみました。
イベントの参加レポートを書くことは今までもありましたが、
「ブログ書く枠」として参加したのは初めてなので、
ちょっとドキドキしています。

僕はどんな人か

実務でいうと、割とバックエンドないし、
フロントエンドとバックエンドの間に入るような仕事をすることが多いです。
フロントエンドばりばり！な感じでは全くないです。
ただ、フロントエンドの実装をやることもありますし、
シングルページアプリケーション(SPA)を実務で実装したこともありますし、、、
ただ、実務経験としてはバックエンドが多いかなぁ、という感じです

フロントエンド好きなので、個人でwebsiteを作ったり、

takahirofujii.com

仲間内のプロジェクトではフロントエンドやったりします。
比較的個人でしかやっていない分、技術的はまだしも、
実際のフロントエンドエンジニアの皆さんがどのように開発されているか、
という知見に疎いです笑

なので、今回の勉強会は非常に新鮮で、楽しませていただきました。

InsideFrontEndとは?

InsideFrontEnd
http://inside-frontend.com/

Opening Talkにて、InsideFrontEndというイベントがどのように開催される運びになったのか？という簡単な説明がありました。

本イベントは、
Yahoo Japan/Cyber Agent/日本経済新聞社
の三社で合同開催されていますが、
元々、各社それぞれフロントエンド系の勉強会を主催されていたそうです。(もしかして、知ってしかるべきだったのかもしれませんが、、w)

会社	イベント
Yahoo Japan	SCRIPTY - イベント一覧 - connpass
CyberAgent	Frontrend powered by CyberAgent, Inc.
日本経済新聞社	Frontend Meetup Tokyo - connpass

どのイベントも結構人がたくさん入っています。
個人的にはFrontEnd Meetup Tokyoで昨年開催された"W3C TAG デベロッパー・サミット"がすごく面白そうだなと、、（今更ながら）
今後、これらのイベント開催もきちんと見ておこう、と思いました。

また、個人的には今まで参加してきたカンファレンスで、
あまり日経さんがこういったスポンサーをされている会に参加したことがなく(知らなかっただけ？)、新鮮でした。
ただ、UIやフロントエンドと日経っていう結びつきは、たしかにすごく強いなって。新聞ってフロントエンドそのものだし。(もちろん新聞だけじゃなく、web版はvisual dataなど今では様々なものがありますが)

参加したセッション

結構聴きたいセッションが被っていて悩んだのですが、ひたすらセミナーBのセッションを聞きました。

B1 : Web over ServiceWorker
https://speakerdeck.com/jxck/web-over-serviceworker
B2 : Web フロントエンドにおけるコンポーネント化のアプローチ
https://speakerdeck.com/1000ch/component-of-web-frontend
B3 : Refactoring CSS: 管理されたカオスへの道のり
B4 : データビジュアライゼーションの作り方
http://shimz.me/slide/inside-frontend_1/#/
B5 : JSON Schema in Web Frontend

アメブロ2016: 実録、アメブロフロントリニューアル275日
がかなり面白そうなので、後で資料を読みこもうと思います。

今回、ちゃんと全セッションのレポートを最初からできれば良いのですが、自分の知見の無さや、コードをまず書いてからレポート書きたいものもあり、順次レポートとして公開する形にできれば幸いです。

レポート : Web フロントエンドにおけるコンポーネント化のアプローチ

speakerdeck.com

今回はこちらのセッションのレポートをさせていただきます。
本セッションでは、

・コンポーネント化に関連した問題
・コンポーネント化をどのように実現・管理するか
・協業実践に向けた方針

などについて述べられていました。

個人的には、SPAの開発を経験してから、
コンポーネント化について考えることが多くなりました。
とはいえ、あまりセッションでこういった話を聞きに行ったこともなく、
そういった意味でもこのセッションを非常に楽しみにしていました。

コンポーネントとは

スライドでは、

ソフトウェアにおいては特定の機能、特に再利用性を考えて汎用に開発されたもの

とありました。

コンポーネント化に関連した問題

スタイルガイドについて

少し前まではスタイルガイドが全てを解決してくれる、、というところから始まりました。

実は、恥ずかしながら(HTML+CSSで管理する)スタイルガイドを運用する形で
開発をそもそもやったことが無く、どんな感じなんだろう・・・??というレベルでした笑

スライドの背景になっていた下記のサイトを見てみました。

The Buffer Style Guide
https://buffer.com/style-guide

とっても綺麗にまとまってます。。。
僕はこれがある状態で(僕自身が)フロントエンドの実装ができたら嬉しいです。

発表者の方は、スタイルガイドを利用した開発でまそもそも開発が上手くいったことがないそうです。
「スタイルガイドを利用した開発フローで上手く行っている所ありますか？」
ということを会場内でアンケートした所、若干名の手があがっていました。上手く行っている所もありそうです。

そこで、なぜスタイルガイドを利用した開発が上手くいかなかったのか、という話になります。

The Buffer Style Guideを見たときにも感じたのですが、

組織構成によっては、"このドキュメントが何のためか"というのがぶれるなと思いました。
セッション/スライドでも話がありましたが

デザイナーがHTML+CSSを修正不能なら悪手

というのはその通りだと思います。
このパターンのコンポーネント化をしたいと思うのは、
大体の場合が
エンジニア側が再利用を促進したい
が発端な気がします。しかし、この流れだと、
デザイナーが一緒にコンポーネント化のビジョンを共有する
ことが難しいと感じました。

デザイナーの手の届かない所でスタイルガイドが管理されてしまうというのが
問題です。

開発が修正したスタイルガイドがデザイナーにキャッチアップされない。
デザインしたものが全てきちんとスタイルガイドに反映されない

ということが発生すると、メンテナンスされなくなっていき、機能しなくなるなと。

そこで、デザインファイルで管理するという話があがっていました。
そうすると、デザイナーが継続してメンテナンスできると。
デザインファイルをコンポーネントの用に管理して(Photoshopの外部ファイル参照?)デザインファイルをコンポーネント管理できたら非常に素敵だな、とは思いました。

綺麗にデザインファイルを管理してもらうメリット、
それがコンポーネント化に繋がっていくというビジョンをデザイナーの方と共有できるといいなと感じました。

クライアントサイド実装の溝

ここでは、デザイナーはページ全体から設計して、
エンジニアはコンポーネントから開発していくことが多いという話がありました。確かに、そういったケースが自然で、
また、それによってデザイナー側にコンポーネント化のメリットが伝わりにくいんじゃないかなとも思いました。

コンポーネント化をどのように実現・管理するか

プラットフォーム毎のコンポーネントを成す技術

ここでは、具体的にHTML+CSSでコンポーネント化を行う際の話がありました。

"HTML+CSSだけスコープがない。"
"CSSはスコープがなく脆く壊れやすい言語"

これは誰もが感じたであろうHTML+CSSの辛さですね。。
ここでは、その対策として最近スタンダードになってきている(?)
CSS Modules, CSS in JS,ShadowDOMが紹介されていました。
CSS Modulesは使ったことがありますが、CSS in JSは使ったことがないので、試してみようと思います。
CSS ModulesとCSS in JSの比較は結構いろんなところでされているようです。

e.g)
http://morishitter.hatenablog.com/entry/2015/09/28/103334
http://postd.cc/modular-css-with-react/
http://blog.kubosho.com/entry/css-in-js

CSS Modules
https://github.com/css-modules/css-modules

import styles from "./style.css";
// import { className } from "./style.css";

element.innerHTML = '<div class="' + styles.className + '">';

webpackでコンパイルする際に、一意で衝突しないクラス名が生成され、styleも当たります。
実装上はそれを意識する必要がありません。

sample site
https://css-modules.github.io/webpack-demo/

CSS in JS
https://github.com/MicheleBertoli/css-in-js

var style = {
  sample: { backgroundColor: "#fff" }
}

var Sample = React.createClass({
  render() { return <div style={style.sample}>HOGE</div>; }
});

こちらは、よりcssをjavascriptの一部の属性として扱っている感じがあります。
ただし、CSS in JS自体はアプローチであり、特にSPAを作る上で使えるライブラリはめちゃくちゃ沢山あるので、それにもよるかも、、。

Shadow DOM
@tonkotsuboy_comさんが共有されていたこちらの記事が分かり易かったです。(が2回以降が見たくなってしまいました。。笑)

Shadow DOMについてはCodeGridさんの記事がわかりやすいです。

→ 先取り、Shadow DOM - Shadow DOMが生まれた理由 | CodeGrid : https://t.co/DNslzi5IiF #insidefe #insidefe_B
— 鹿野壮（かのたけし） (@tonkotsuboy_com) 2017年2月25日

実装例に関しては、@kei_n_n_iekさんが共有されていた記事が大変わかりやすかったです。

shadow DOM めもhttps://t.co/bQkqMQ2yr8 https://t.co/HcgaHX0uku #insideFE
— kei (@kei_n_n_iek) 2017年2月25日

こういった技術の登場により、スコープが無く苦労していた
HTML,CSSにも概ね、コンポーネントを意識した実装方法が可能になってきました。

協業実践に向けた方針

あまりこういった話も直接セッションで来たことがなかったので新鮮でした。
(よく議論されていることだとは思うのですが、、)

ここで記載されていた内容で、自分が一番共感できた部分は、

一方通行な開発にならないこと

これにつきます。
コンポーネント化にしても、スタイルガイドにしても課題解決の一つの手段であるはずなので、課題がきちんと共有できていないと、
小さいサイト規模からのコンポーネントや、デザインファイルのコンポーネント型の管理は非常に難しいのではないでしょうか。

まず大切になってくるのは

パーツを再利用することのメリット(一貫性や、開発速度の向上)の共有
コンポーネント化をしたいと思う人が、裏で思っている課題の共有
- 毎回似通ったボタンをいちいち実装しないといけない
- 一貫性がなく、文言変更や、特定のデザイン変更があった場合の修正がすごく大変
- パーツの使い回しができないことによって、開発速度が落ちていると感じる
- デザインをする際に細かいパーツの設計に毎回時間をとられ、全体のディレクションやUX設計に時間がとれない
- デザイナー毎にデザインのばらつきが出すぎて、一貫性が弱い

個人的にはメリットの共有よりも、課題の共有の方が共通認識を持ちやすいと思います。