青空コメントアウト

WEBのこと、デザインのこと、ご飯のこと、趣味のこと。青空の向こうの誰かに届きますように。

Webの明るい未来はWebComponentに託された!

このエントリーをはてなブックマークに追加


まいどです。
今更だけど、WebComponentのことあんまり知らなかったあろえりーな(@aloerina_)です。しょんぼりです…。

というわけでWebComponentが何なのか調べてきました。先輩!勉強不足ですみませんでした!ということで成果です(メモです)。




そもそも何なのよ?

すごくざっくり言うと画面を構成するための要素を部品化する仕組みです(ざっくりすぎる)。
複雑なWEBアプリケーションをつくるときは、それなりにきちんとした仕組みを作らないとあとでデザイン修正や不具合修正が大変になります、言わずもがな。そうならないために細かい部品に区切ってつくっておいて、あとである部品だけ修正したり、同じ部品を使い回したりできるようにしよう!といういわゆるオブジェクト指向的なモノなのかなと感じました。

最近はWEBでできることが増えてきて、WEBアプリの複雑さもすごいことになってきていて、その煽りを受けてかフロントサイドのコンポーネント化が流行ってきている気がします。ですので、今のうちに(というか今ならまだ間に合うので)キャッチしておくと良さそうな仕組みです。

で、再びざっくりとWebComponentの仕組みを説明すると、以下4つで構成されています。

  • カプセル化され、外部から隠蔽されたDOMをつくれる Shadow DOM
  • HTML上で再利用できるDOMをつくれる HTML Templates
  • オリジナルのElementを定義できる Custom Elements
  • <link>をつかって外部HTMLを読み込める HTML Imports

f:id:cocoro27:20160617014851j:plain




何がそんなにすごいわけ?

Shadow DOM でHTMLにスコープを導入

HTML/CSSには、オブジェクト指向に必須のスコープの概念がないという致命的な欠点がありますが、それを補います。DOMの一部をカプセル化することで、Javascriptなどからアクセスすることを防ぐことができます。

スコープとは
あるひとつのオブジェクトや変数などに、どこからアクセスできるかを定義するもの。どこからでもアクセスできるものをpublic、狭い範囲からしかアクセスできいないものをprivateなんて呼んだりしますが、それはプログラム言語を学んでから知れば十分なことです。



HTML Templates で手堅くDOMを使い回す

テンプレートは、何があってもブラウザにいじくりまわされたくない HTML の塊を置いておく場所なのです。

と言われるそうですね。その通りだと思います。

しかもこのTemplatesはアクティベート(有効化)されるまでレンダリングされないとのことで、とってもECO。アクティベートのトリガーはJavascriptに書かれるので、マークアップ専門の人にはちょっとハードルを感じるのかもしれませんが…。



Custom Elements で根深いDOMツリーの可読性アップ

Div>Div>Div>Div>Div>Div…みたいなDiv地獄を読みやすいかたちにできちゃいます。具体的には、新しい要素のタグをつくれちゃいます。

こんなふうに、意味を読み取れる単位でDivを(Elementを)ひとまとめにして、オリジナルのElementにして置き換えることができるのです。



外部HTMLを使いまわしてコード記述が激減

外部CSSを読み込んだ経験があれば、CSSの分割することや使い回すことに便利さを実感していると思います。同じことをHTMLについてもしよう!というのがHTML Importsです。今後使い勝手のいいHTMLがCDN経由で配布される日がくるのかもしれないです。

ただ、外部HTMLを読み込むということはリクエスト回数が増えるということなので、速度劣化につながらないかがやや不安です。minify(圧縮)の仕組みと合わせて発展していく機能なのかなと勝手に憶測しています。




WebComponentに期待すること

フロントのコンポーネント化については、最近それに着眼したライブラリも増えてきているのでそれらとどうすみ分けていくのかが気になるところ…。それよりも描画速度を改善できるんじゃないかなってことに期待しています。Templatesを使えばDOMのトラバースを短縮できるし、Importsを使えば初期描画に必要な最低限だけを本体のHTMLに書いておいて、その他は外部HTMLをLazyLoad(遅延読込)することもできるかもしれない…。

ユーザビリティの向上にはやっぱり応答速度を良くすることが一番先決なんじゃないかなと。思ったりするわけです。




最後に一言

つまるところ、所感はフロントのソースがどんどん構造化されて読みやすくなる反面、複雑なバグの温床が増えるのかもなあなんていう小並感的なものでした。当然のことしか考えてないですね。

えらそうに理屈ばかり知識ばかり語っていても仕方ないので、次回は(いずれは)実践編書こうと思います。ではまた。

TOP