[訳]Web Componentsって何?なぜ私たちにとって重要なの?
20379 ワード
原文リンクWhat are WebComponents and why are they important?
サマリ
まず未来のWebComponent標準を見て、WebComponentsの書き方を簡単に理解して、最後にその重要性を話します.
概要
この記事では、WebComponent規格について簡単に説明し、どのブラウザがWebComponentsをサポートし始めたのか、WebComponentsがどのような問題を解決できるのか、Web開発の重要性について説明します.Vanilla Javascriptを使用して簡単なWebComponentを作成する方法を知ることができます.私はまた、その潜在的な優位性について自分の拙見を共有します.
Web componentsとは?
近年、web開発者たちはプラグインやモジュールの形式でネット上で自分のコードを共有し、他の開発者たちがこれらの優秀なコードを多重化するのに便利である.同じ物語が絶えず発生し、JavaScriptファイルが多重化され、CSSファイルが多重化され、もちろんHTMLクリップもあります.しかし、これらの導入コードがあなたのサイトやweb appを破壊しないことを祈らなければなりません.WebComponentsはこのような問題の最良の良薬であり、標準化された非侵入的な方法でコンポーネントをカプセル化し、各コンポーネントは自身のHTML構造、CSSスタイル、JavaScriptコードを整理することができ、ページ上の他のコードに干渉しない.
The Shadow DOM
皆さんは以前shadow DOMを聞いたことがあるかもしれませんが、shadow DOMとはいったい何ですか?開発者はshadow DOMによってドキュメントストリームに他の要素と完全に独立したサブDOMツリー(sub-DOM trees)を作成することができ、この特性により、独立した機能を持つコンポーネントをカプセル化することができ、何気なく他のDOM要素に干渉しないことを保証することができる.shadow DOMは標準のDOMと同様に、そのスタイルを設定したり、JavaScriptで動作を操作したりすることができます.プライマリ・ドキュメント・ストリームとshadow DOMに基づいて作成された独立したコンポーネントとの間の干渉がないため、コンポーネントの多重化も非常に簡単で便利になります.
HTMLテンプレート
Angular JSのような現代のJavaScriptフレームワークを使ったことがある限り、HTMLテンプレートには慣れているに違いありません.開発者はテンプレートを使用してHTMLコードセグメントを多重化し、HTML 5規格ではJavaScriptフレームワークを必要とせずにテンプレートを簡単に使用できます.
HTMLテンプレートのインポート
テンプレートにHTMLコードブロックとサブDOMツリーを作成し、異なる物理ファイルでコードを整理できます.これらのファイルは、PHPファイルでJavaScriptファイルを参照するように、
カスタム要素
コンポーネントを参照するために意味化されたカスタム要素を宣言し、JavaScriptでカスタム要素とテンプレート、shadow DOMとの関連付けを確立し、
最初のWebComponentを書きます
WebComponentsについてある程度知っているはずですが、簡単な例を通じて、上記の退屈な概念をよりよく理解できると思います.次のコードは、最も簡単なWebComponentがHTMLとスタイルコードを
この簡単な例では、多重化しやすく、メンテナンス可能なWebComponentを作成する方法を示します.
WebComponent互換性
「確かにdiaoですが、ニマはいつ『本物』に使えますか?」と言うかもしれません.「今なら少年が使える」と教えてあげます.次の表は、WebComponentの各プロパティに対する主流ブラウザの互換性を示しています.予想外にBlinkベースのブラウザがリードしています.上記の表は、最も簡単なWebComponentの例でもChromeまたはOperaで実行しなければならないことを明確に示しています.
空きをうめる
ほとんどのブラウザではWebComponentはサポートされていませんが、Webcomponentsjsという互換ライブラリがあり、WebComponentをサポートされていないブラウザで実行することができます.このライブラリをプロジェクトに導入すれば、上記の例のようにWebComponentsを使用できます.
WebComponentsの重要性
WebComponentsは現在のWeb開発モデルをどのように変更しますか?本稿の冒頭では,「標準化された非侵入方式でコンポーネントをカプセル化する」という答えが示されているが,これはいったいどのようなメリットをもたらすのだろうか.
無害プラグイン
この文書では、開発者がshadow DOMを使用してサブDOMツリーを作成でき、ページ上のCSSスタイルやJavaScriptスクリプトに影響されないことについて説明しました.明らかな利点は、サードパーティ製コンポーネントを導入するときに、Webサイトの他の機能に影響を与える心配がないことです.開発者にとって、無害プラグインの開発はもっと簡単になりました.次の例では,先ほど書いたWebComponentを用いて,このパッケージの独立性を示した.WebComponentの内部に
一労永逸
標準的な目的は汎用性の向上です.WebComponentsが広くサポートされると、他のプロジェクトでどのような技術が使われているかを考慮することなく、より一般的なコンポーネントを開発することができます.jQueryに対してプラグインを書く必要はありません.Angular JSのためにdirectivesを書く必要はありません.もうEmberではありません.jsはaddonsを書きます.一労永逸は、WebComponentsがもたらした最大のメリットです.フルタイムのAngular JS開発者として、jQueryプラグインをdirectivesに翻訳してから、私のプロジェクトで使うことがよくあります.これらの仕事は非常に煩雑です.プログラマは、あるフロントエンドフレームワークに限定されるべきではありませんが、現実的には、異なるフレームワークのコードが共有できないため、フロントエンドフレームワークごとに制限されています.WebComponentsは私たちを水深火熱から救うことができます.
メンテナンスとテスト
このような標準で作成されたコンポーネントは、より良好なメンテナンス性を有する.ベストプラクティスは、より迅速に採用され、より迅速で信頼性の高いWebアプリケーションをもたらします.テストはより簡単になり、テスト仕様もコンポーネントとともに公開されます.
Abstraction
WebComponentsで複雑な機能を開発することができ、複雑なWebアプリケーションの開発に少ない労力を費やすことができます.これらのコンポーネントを組み立てて、彼らの間で通信できることを保証するだけで、完全なアプリケーションを組み立てることができます.Angular JS 1.xを例にとると、controllersを書く必要はありません.directivesを書く必要はありません.そんなにscopeを書く必要はありません.基本的なサービスとルーティングを提供すればいいです.もちろんAngular 2.0はWebComponentsを計画しています.
HTMLの物語
HTML 5仕様は、
伝統的なHTML表記
WebComponentsの意味化表記
上記の例は比較的簡単であるが,両者の著しい違いを見ることができる.1つ目の例は標準的なHTMLタグを使用しており、コードから最終的なレンダリング結果を直接見るのは難しいが、2つ目の例はHTML 5タグとカスタムタグを使用しており、コードレベルからより多くの有用な情報を提供している.これらの意味を有するラベルから、ページの各ブロックの意味、例えば
もう一つの大きな穴
上記の利点はWeb開発をより美しくすることができて、あなたが私と同じように興奮して期待していることを望んでいます.しかし...いくつかの問題をもたらす可能性もあります.歴史は何度もWeb標準の実際の応用が複数の分岐に分裂する可能性があることを証明し、私たちに困難な選択をもたらす可能性があります.このようなこともWebComponentsに起こるのではないかと心配しています.現在、WebComponent規格に基づく3つのフレームワークがあり、低レベルブラウザとの互換性が優れています.これはもともと良いことですが、WebComponentsアプリケーションを開発する際に3つの選択肢があることを意味しています.X-Tag、Polymer、Bosonicです.WebComponent規格をサポートしている以上、Polymerに基づいて開発されたコンポーネントコードはx-tagコンポーネントに使用できますか?逆に?次の例を見てみましょう.
X-Tagアセンブリ(ソースコード)
Polymerコンポーネント(ソースコード)
待って、変に見えますね.私はまだこの2つのフレームワークを開発したことがないことを認めて、杞憂だと教えてくれる人はいますか?しかし、これは本当に2つの完全に互換性のない方法でWebComponentsを開発しているように見えます.
私はAngular 2に対しても同様の心配を持っています.彼らはWebComponent標準を完全に支持していると主張していますが、明らかにフレームワークのレベルのものがたくさんあります.Angularチームは、どうすればいいのか、なぜそうすればいいのか、利益が弊害より大きいことを望んでいるのではないでしょうか.Angularチームのメンバーがこの文章を見て、WebComponentsのAngular 2での使い方を紹介できれば、それに越したことはありません.
前述したように、意味化されたHTMLタグのメリットについては、コードを読むことで意味をすばやく理解できます.もちろん、開発者が意味化ラベルと意味化されたカスタム属性を使用して開発するかどうかにも依存します.さらに重要なのは、コミュニティができるだけ早く優秀なベストプラクティスを提供し、一般的な開発者をより良い習慣に導くことです.
まとめ
WebComponentsはWeb開発を徹底的に変えることができますが、まだ時間がかかります.フロントエンドコミュニティでは、WebComponentsを本当に利用できるようにするには、コンポーネント型Web開発の利便性を享受するために、多くの作業が必要です.
君はここにいるorgこのサイトはWebComponentsについてもっと知っています.彼らのGitHubアカウントには学習に適した例がたくさんあり、本文の例もその中から来ています.
私は喜んであなたたちの本文に対する評論とWebComponentに対する見解を聞きます.
サマリ
まず未来のWebComponent標準を見て、WebComponentsの書き方を簡単に理解して、最後にその重要性を話します.
概要
この記事では、WebComponent規格について簡単に説明し、どのブラウザがWebComponentsをサポートし始めたのか、WebComponentsがどのような問題を解決できるのか、Web開発の重要性について説明します.Vanilla Javascriptを使用して簡単なWebComponentを作成する方法を知ることができます.私はまた、その潜在的な優位性について自分の拙見を共有します.
Web componentsとは?
近年、web開発者たちはプラグインやモジュールの形式でネット上で自分のコードを共有し、他の開発者たちがこれらの優秀なコードを多重化するのに便利である.同じ物語が絶えず発生し、JavaScriptファイルが多重化され、CSSファイルが多重化され、もちろんHTMLクリップもあります.しかし、これらの導入コードがあなたのサイトやweb appを破壊しないことを祈らなければなりません.WebComponentsはこのような問題の最良の良薬であり、標準化された非侵入的な方法でコンポーネントをカプセル化し、各コンポーネントは自身のHTML構造、CSSスタイル、JavaScriptコードを整理することができ、ページ上の他のコードに干渉しない.
The Shadow DOM
皆さんは以前shadow DOMを聞いたことがあるかもしれませんが、shadow DOMとはいったい何ですか?開発者はshadow DOMによってドキュメントストリームに他の要素と完全に独立したサブDOMツリー(sub-DOM trees)を作成することができ、この特性により、独立した機能を持つコンポーネントをカプセル化することができ、何気なく他のDOM要素に干渉しないことを保証することができる.shadow DOMは標準のDOMと同様に、そのスタイルを設定したり、JavaScriptで動作を操作したりすることができます.プライマリ・ドキュメント・ストリームとshadow DOMに基づいて作成された独立したコンポーネントとの間の干渉がないため、コンポーネントの多重化も非常に簡単で便利になります.
HTMLテンプレート
Angular JSのような現代のJavaScriptフレームワークを使ったことがある限り、HTMLテンプレートには慣れているに違いありません.開発者はテンプレートを使用してHTMLコードセグメントを多重化し、HTML 5規格ではJavaScriptフレームワークを必要とせずにテンプレートを簡単に使用できます.
HTMLテンプレートのインポート
テンプレートにHTMLコードブロックとサブDOMツリーを作成し、異なる物理ファイルでコードを整理できます.これらのファイルは、PHPファイルでJavaScriptファイルを参照するように、
<link>ラベルで導入されます.カスタム要素
コンポーネントを参照するために意味化されたカスタム要素を宣言し、JavaScriptでカスタム要素とテンプレート、shadow DOMとの関連付けを確立し、
<my-custom-element></my-custom-element>などのカスタムラベルをページに挿入するとパッケージされたコンポーネントが得られます.Angular JSには似たような書き方がたくさんあります.最初のWebComponentを書きます
WebComponentsについてある程度知っているはずですが、簡単な例を通じて、上記の退屈な概念をよりよく理解できると思います.次のコードは、最も簡単なWebComponentがHTMLとスタイルコードを
<template>で包み、JavaScriptでカスタムラベル<favorite-colour>にバインドする要素を示しています.<!-- WebComponent example based off element-boilerplate: https://github.com/webcomponents/element-boilerplate -->
<template>
<style> .coloured { color: red; } </style>
<p>My favorite colour is: <strong class="coloured">Red</strong></p>
</template>
<script> (function() { // Creates an object based in the HTML Element prototype var element = Object.create(HTMLElement.prototype); // Gets content from <template> var template = document.currentScript.ownerDocument.querySelector('template').content; // Fires when an instance of the element is created element.createdCallback = function() { // Creates the shadow root var shadowRoot = this.createShadowRoot(); // Adds a template clone into shadow root var clone = document.importNode(template, true); shadowRoot.appendChild(clone); }; document.registerElement('favorite-colour', { prototype: element }); }()); </script><link />でWebComponentファイルを導入し、<favorite-colour>のラベルを追加して、次のコードで示すようにWebComponentをページに追加します.<!DOCTYPE html>
<html>
<head lang="en">
<meta charset="UTF-8">
<title>My First WebComponent</title>
<link rel="import" href="components/favorite-colour.html" />
</head>
<body>
<favorite-colour></favorite-colour>
</body>
</html>この簡単な例では、多重化しやすく、メンテナンス可能なWebComponentを作成する方法を示します.
WebComponent互換性
「確かにdiaoですが、ニマはいつ『本物』に使えますか?」と言うかもしれません.「今なら少年が使える」と教えてあげます.次の表は、WebComponentの各プロパティに対する主流ブラウザの互換性を示しています.予想外にBlinkベースのブラウザがリードしています.上記の表は、最も簡単なWebComponentの例でもChromeまたはOperaで実行しなければならないことを明確に示しています.
空きをうめる
ほとんどのブラウザではWebComponentはサポートされていませんが、Webcomponentsjsという互換ライブラリがあり、WebComponentをサポートされていないブラウザで実行することができます.このライブラリをプロジェクトに導入すれば、上記の例のようにWebComponentsを使用できます.
WebComponentsの重要性
WebComponentsは現在のWeb開発モデルをどのように変更しますか?本稿の冒頭では,「標準化された非侵入方式でコンポーネントをカプセル化する」という答えが示されているが,これはいったいどのようなメリットをもたらすのだろうか.
無害プラグイン
この文書では、開発者がshadow DOMを使用してサブDOMツリーを作成でき、ページ上のCSSスタイルやJavaScriptスクリプトに影響されないことについて説明しました.明らかな利点は、サードパーティ製コンポーネントを導入するときに、Webサイトの他の機能に影響を与える心配がないことです.開発者にとって、無害プラグインの開発はもっと簡単になりました.次の例では,先ほど書いたWebComponentを用いて,このパッケージの独立性を示した.WebComponentの内部に
colourというクラスが定義され、colorのプロパティがredに設定されています.ホームページのcolourクラスのcolorはgreenで!importantに設定されていますが、WebComponentでの色は赤で表示されています.Githubにアクセスしてサンプルコードを取得できます.一労永逸
標準的な目的は汎用性の向上です.WebComponentsが広くサポートされると、他のプロジェクトでどのような技術が使われているかを考慮することなく、より一般的なコンポーネントを開発することができます.jQueryに対してプラグインを書く必要はありません.Angular JSのためにdirectivesを書く必要はありません.もうEmberではありません.jsはaddonsを書きます.一労永逸は、WebComponentsがもたらした最大のメリットです.フルタイムのAngular JS開発者として、jQueryプラグインをdirectivesに翻訳してから、私のプロジェクトで使うことがよくあります.これらの仕事は非常に煩雑です.プログラマは、あるフロントエンドフレームワークに限定されるべきではありませんが、現実的には、異なるフレームワークのコードが共有できないため、フロントエンドフレームワークごとに制限されています.WebComponentsは私たちを水深火熱から救うことができます.
メンテナンスとテスト
このような標準で作成されたコンポーネントは、より良好なメンテナンス性を有する.ベストプラクティスは、より迅速に採用され、より迅速で信頼性の高いWebアプリケーションをもたらします.テストはより簡単になり、テスト仕様もコンポーネントとともに公開されます.
Abstraction
WebComponentsで複雑な機能を開発することができ、複雑なWebアプリケーションの開発に少ない労力を費やすことができます.これらのコンポーネントを組み立てて、彼らの間で通信できることを保証するだけで、完全なアプリケーションを組み立てることができます.Angular JS 1.xを例にとると、controllersを書く必要はありません.directivesを書く必要はありません.そんなにscopeを書く必要はありません.基本的なサービスとルーティングを提供すればいいです.もちろんAngular 2.0はWebComponentsを計画しています.
HTMLの物語
HTML 5仕様は、
<section>、navなどの新しい意味化ラベルをもたらす.これは,コードの詳細を詳しく読まなくても開発者の意図を理解できると考えている.WebComponentsは、コンポーネントのHTMLコードの面で、カスタム要素と属性がより多くの意味を表現できるように、HTMLを使用する方法を徹底的に変更します.次の例に示します.伝統的なHTML表記
<!-- PAGE NAVIGATION -->
<div>
<ul>
<li>Home</li>
<li>About</li>
<li>Contact</li>
</ul>
</div>
<!-- CONTENT AREA -->
<div>
<p>Here is some simple content in the content area.</p>
</div>
<!-- GALLERY -->
<div>
<img src="animage1.png" />
<img src="animage2.png" />
<img src="animage3.png" />
<img src="animage4.png" />
<img src="animage5.png" />
</div>
<!-- FOOTER -->
<div>
<p>A simple footer</p>
</div>WebComponentsの意味化表記
<page-navigation data-position="top"></page-navigation>
<content data-theme="dark">
<p>Here is some simple content in the content area.</p>
</content>
<image-gallery data-fullscreen="true">
<img src="animage1.png" />
<img src="animage2.png" />
<img src="animage3.png" />
<img src="animage4.png" />
<img src="animage5.png" />
</image-gallery>
<footer>
<p>A simple footer</p>
</footer>上記の例は比較的簡単であるが,両者の著しい違いを見ることができる.1つ目の例は標準的なHTMLタグを使用しており、コードから最終的なレンダリング結果を直接見るのは難しいが、2つ目の例はHTML 5タグとカスタムタグを使用しており、コードレベルからより多くの有用な情報を提供している.これらの意味を有するラベルから、ページの各ブロックの意味、例えば
page-navigationおよびfooterをすぐに理解することができる.他の情報は、data-fullscreenおよびdata-positionのようなカスタム属性によって、ページにどのようなデータが伝達されるかをよく説明することができる.もう一つの大きな穴
上記の利点はWeb開発をより美しくすることができて、あなたが私と同じように興奮して期待していることを望んでいます.しかし...いくつかの問題をもたらす可能性もあります.歴史は何度もWeb標準の実際の応用が複数の分岐に分裂する可能性があることを証明し、私たちに困難な選択をもたらす可能性があります.このようなこともWebComponentsに起こるのではないかと心配しています.現在、WebComponent規格に基づく3つのフレームワークがあり、低レベルブラウザとの互換性が優れています.これはもともと良いことですが、WebComponentsアプリケーションを開発する際に3つの選択肢があることを意味しています.X-Tag、Polymer、Bosonicです.WebComponent規格をサポートしている以上、Polymerに基づいて開発されたコンポーネントコードはx-tagコンポーネントに使用できますか?逆に?次の例を見てみましょう.
X-Tagアセンブリ(ソースコード)
<!-- Import X-Tag -->
<script src="../bower_components/x-tag-core/src/core.js"></script>
<template>
<p>Hello <strong></strong> :)</p>
</template>
<script> (function(window, document, undefined) { // Refers to the "importer", which is index.html var thatDoc = document; // Refers to the "importee", which is src/hello-world.html var thisDoc = document._currentScript.ownerDocument; // Gets content from <template> var template = thisDoc.querySelector('template').content; xtag.register('hello-world', { lifecycle: { created: function() { // Caches <strong> DOM query this.strong = template.querySelector('strong'); // Creates the shadow root this.shadowRoot = this.createShadowRoot(); this.uiSetWho(); }, attributeChanged: function() { this.uiSetWho(); } }, accessors: { who: { attribute: {}, get: function(){ return this.getAttribute('who') || "World" }, set: function(value){ this.xtag.data.who = value; } } }, methods: { uiSetWho: function() { // Sets "who" value into <strong> this.strong.textContent = this.who; // Removes shadow root content this.shadowRoot.innerHTML = ''; // Adds a template clone into shadow root var clone = thatDoc.importNode(template, true); this.shadowRoot.appendChild(clone); } } }); })(window, document); </script>Polymerコンポーネント(ソースコード)
<!-- Import Polymer -->
<link rel="import" href="../bower_components/polymer/polymer.html">
<!-- Define your custom element -->
<polymer-element name="hello-world" attributes="who">
<template>
<p>Hello <strong>{{who}}</strong> :)</p>
</template>
<script> Polymer('hello-world', { who: 'World' }); </script>
</polymer-element>待って、変に見えますね.私はまだこの2つのフレームワークを開発したことがないことを認めて、杞憂だと教えてくれる人はいますか?しかし、これは本当に2つの完全に互換性のない方法でWebComponentsを開発しているように見えます.
私はAngular 2に対しても同様の心配を持っています.彼らはWebComponent標準を完全に支持していると主張していますが、明らかにフレームワークのレベルのものがたくさんあります.Angularチームは、どうすればいいのか、なぜそうすればいいのか、利益が弊害より大きいことを望んでいるのではないでしょうか.Angularチームのメンバーがこの文章を見て、WebComponentsのAngular 2での使い方を紹介できれば、それに越したことはありません.
前述したように、意味化されたHTMLタグのメリットについては、コードを読むことで意味をすばやく理解できます.もちろん、開発者が意味化ラベルと意味化されたカスタム属性を使用して開発するかどうかにも依存します.さらに重要なのは、コミュニティができるだけ早く優秀なベストプラクティスを提供し、一般的な開発者をより良い習慣に導くことです.
まとめ
WebComponentsはWeb開発を徹底的に変えることができますが、まだ時間がかかります.フロントエンドコミュニティでは、WebComponentsを本当に利用できるようにするには、コンポーネント型Web開発の利便性を享受するために、多くの作業が必要です.
君はここにいるorgこのサイトはWebComponentsについてもっと知っています.彼らのGitHubアカウントには学習に適した例がたくさんあり、本文の例もその中から来ています.
私は喜んであなたたちの本文に対する評論とWebComponentに対する見解を聞きます.