ナベリヲログ

#1 Web Components とは何か

この記事は僕が所属している会社で開発している SmartHR UI という React コンポーネントライブラリの未来を見据えて考えたことを綴った社内向けの記事に加筆修正をしてこのブログに持ってきたものになります。
SmartHR UI というライブラリは OSS として開発しているものだし、あまり社内に閉じている意味もないと思ったのでこのブログに持ってきたという感じです。
この記事1つで完結するものではなく、気が向いたときに書いていく続きものになります。

以下、社内向けドキュメントから持ってきた部分になります。


これは何

この記事はフロントエンドエンジニアである nabeliwo が SmartHR UI の将来の更なる発展を見据えて、 Web Components という可能性を模索する、そんな記事です。
あくまで可能性の模索、夢を旅するお話なので、別に今後そうしていくよ宣言とかではないので気軽に流し読みしてください。

第一回目はそもそも Web Components ってなんなのよ、という話です。

Web Components is 何

MDN によるとても短い説明を引用すると、「再利用可能なカスタム要素を作成し、ウェブアプリの中で利用するための、一連のテクノロジーです。コードの他の部分から独立した、カプセル化された機能を使って実現します。 」ということです。

Web Components | MDN

わかりやすく言うと、例えば SmartHR UI でやっているような、 Button だったり Input だったり Tooltip だったりのようなコンポーネントを、カスタム要素と呼ばれる特殊な HTML タグとして定義して、ライブラリやフレームワークを問わず、純粋な HTML としてどこからでも再利用できるようにする技術のことを Web Components と呼びます。
Web Components で定義された要素は、振る舞いや見た目がカプセル化され、外になんの影響も与えないし外からの影響を受けることもないので、再利用する上でとても便利なパーツになります。

Web Components の何が良いのか

これだけ聞いても、あまり良さがわからないかもしれません。それって別に、今でも SmartHR UI って SmartHR 内の全てのプロダクトから利用できるし何が変わるの?って話ですよね。
現状 SmartHR UI が SmartHR 内で便利に使えているのは一つの大前提を社内で共有できているからです。
それは、 React を使ってアプリケーションを作ることです。

社内にいるとあまり実感しづらいですが、個人的にはこれは結構すごいことなのかなと思っています。
良いか悪いかは別の話ですが、世の中の SPA を何個も社内で量産しているような会社では、意外と社内のフロントのスタックが揃ってないみたいな話はよく聞きます。

そして何よりも大事なのは、弊社がプラットフォーム化構想というビジョンを持っているということです。
【SmartHR Next 2018】SmartHRが描く未来。AI時代を見据えた「プラットフォーム化構想」とは?

この未来を達成するために大事な要素として、公開 API を開発者にとって使いやすいものにしていく、というのがあると思います。そして個人的に、開発者にとって使いやすい UI ライブラリを用意してあげるというのもとても大事なことなのかな、と考えています。
それがどう Web Components に繋がるかというと、 Web Components で SmartHR UI を作るようにすると、 SmartHR UI の利用者がReact 縛りから解放されます。

世の中には React と同じくらい Vue のユーザがいます。他にも Angular だったり、その他のフレームワークだったり、 Vanilla JS でアプリケーションを作っている人もいます。
そんな人たちからしたら、せっかく弊社で用意している SmartHR UI を利用して簡単にビューを構築できるのに、自分が React を使っていないばっかりに自分で再実装をしないといけない…嗚呼…無情…となって悲しい思いをさせてしまいますね。

そこで Web Components 化された SmartHR UI があると、 Vue だろうが Angular だろうが Vanilla だろうがなんでもござれ状態になります。真の意味で誰でも使える UI ライブラリという存在になります。
これは社外だけではなくきっと社内にも意味はあって、 SmartHR UI という資産を使って Plus アプリを爆速で作るために今はほぼ React 決め打ちになっていますが、 Web Comopnents 化されている場合であればアサインされた開発者の得意なスキルに応じてフロントのスタックを大きく変えても資産を使用して開発速度をあげることができます。
まあこれは別のいろんな問題が出てきそうなので本当にそれが良いと言えるかはもっと考える必要はありそうですが。

そんなわけで Web Comonents にはロマンが詰まっていると、僕はそう思っています。

Web Components の構成要素

ではそんな Web Components の技術的な要素を見ていきましょう。
Web Components は以下の3つの主要な技術で構成されています。

  • カスタム要素
  • Shadow DOM
  • HTML テンプレート

それぞれの詳細な仕様などの解説は別の機会にするとして、今回はざっと理解できるように簡単に紹介するだけに留めます。

カスタム要素

有効な HTML として、独自に定義した HTML タグを作成できるようにするための JavaScript API が存在します。
これを使うと、例えば <smarthr-button>これは SmartHR のボタンです</smarthr-button> みたいな HTML を正しい HTML として記述できるようになります。

Shadow DOM

Virtual DOM, 仮想 DOM ではありません。 Shadow DOM です。

カプセル化された Shadow DOM ツリーを作成できます。
Shadow DOM ツリーは、メインドキュメントの DOM とは別にレンダリングされるので、ドキュメントの他の部分との重複を気にする必要はなくなるし、振る舞いや見た目が外からの影響を全く受けなくなるし外に影響を与えなくなります。

例えば現時点でも、 audio タグを HTML 上に記述すると、音源を操作するためのコントローラーが画面上に表示されますが、そのコントローラーはカプセル化され外から触ることができず、振る舞いや見た目が独立したものになっています。
その状態を自分で作れるようになります。

HTML テンプレート

<template><slot> という HTML の要素によって、 Web ページ内に表示されないマークアップのテンプレートを作れます。
このテンプレートをカスタム要素の構造体の基礎として、それを再利用することになります。

JavaScript 側でテンプレートを作ることが多いので、あまりこの機能が使われることは多くはなさそうな気配がしています。

【おまけ】 HTML インポート

以前は HTML インポートも Web Components を構成する1つの要素でしたが、今は廃止されてしまったのでおまけでの紹介とします。

HTML 内で <link> を使用して HTML ファイルを import できる仕様です。こんな感じ <link rel="import" href="myfile.html"> になります。
先述した HTML テンプレートを HTML インポートで取得する、みたいな流れのイメージです。

廃止された理由としては、それって ES Modules の import でできるよね?ということでした。まあ確かに。

締め

今回は第一回目なので Web Comopnents とはどういうものなのか、そこに詰まっているロマン、みたいな浅めのわかりやすい話だけをしました。
次回は自分の勉強がてら Web Components の仕様を深掘りしたり実際の実装方法をコードを交えて紹介したりとか、そんなことができたらな〜と考えています。

この記事は気分が乗ったときに書くので次回がいつなのか、そもそも次回があるのか、というのは今の僕にはわかりません。おわり。

ホームに戻る