前年、Polymer チームは多くの時間をかけて独自の要素の作成方法をデベロッパーに教えてきました。これによりエコシステムが急成長し、その大部分を支えているのが Polymer の Core 要素と Paper 要素、そして Mozilla のチームによって作成された Brick 要素です。
デベロッパーが独自の要素を作成することに慣れ、アプリケーションの構築について考えるようになると、多くの疑問が浮かび上がります。
- アプリの UI をどのように構成すればよいでしょうか。
- さまざまな状態にどのように移行しますか？
- パフォーマンスを向上させるための戦略はどのようなものですか。
- また、オフライン エクスペリエンスを提供するにはどうすればよいでしょうか。
Chrome Dev Summit では、少人数の連絡先アプリケーションを作成し、その構築プロセスを分析することで、こうした質問に答えようとしました。次の結果が見つかりました。
構造
Web Components の中心となる要素は、アプリケーションをモジュールに分割して組み合わせて再利用できるようにすることです。Polymer の core-* 要素と paper-* 要素を使用すると、paper-tooltip や paper-icon-button のような小さな断片からでも簡単に作業を開始できます。
また、コンポジションの力によって、コンポーネントを任意の数の要素と組み合わせて、アプリケーションのスキャフォールドを作成します。
汎用的なスキャフォールドを用意したら、独自の CSS スタイルを適用してブランド独自のエクスペリエンスに変えることができます。コンポーネントを使用してこれを行うことの利点は、同じアプリ作成プリミティブを活用しながら、まったく異なるエクスペリエンスを作成できることです。土台が整ったら、コンテンツについての検討に移ります。
大量のコンテンツを処理するのに特に適している要素の 1 つは、core-list です。
core-list はデータソース（基本的にはオブジェクトの配列）に接続でき、配列のアイテムごとにテンプレート インスタンスを生成します。テンプレート内で、Polymer のデータ バインディング システムを活用してコンテンツをすばやく作成できます。
切り替え効果
アプリのさまざまなセクションを設計、実装したら、次のタスクは、実際にそれらのセクション間を移動する方法を見つけることです。
core-animated-pages はまだ試験運用版の要素ですが、アプリの状態間の遷移に使用できるプラグイン可能なアニメーション システムが用意されています。
しかし、アニメーションはパズルの半分にすぎず、アプリケーションは URL を適切に管理するためにそれらのアニメーションをルーターと組み合わせる必要があります。
Web Components のルーティングには、命令型と宣言型という 2 種類があります。プロジェクトのニーズによっては、core-animated-pages をいずれかのアプローチと組み合わせることもできます。
命令型ルーター（Flatiron の Director など）は一致するルートをリッスンし、選択されたアイテムを更新するように core-animated-pages に指示できます。
これは、ルートが一致した後、次のセクションが移行する前になんらかの作業を行う必要がある場合に役立ちます。
一方、宣言型ルーター（app-router など）を使用すると、実際にはルーティングと core-animated-pages を 1 つの要素に結合できるため、この 2 つの管理が効率化されます。
より細かい制御が必要な場合は、more-routing などのライブラリをご覧ください。これは、データ バインディングを使用して core-animated-pages と組み合わせることで、両方の長所を活かすことができます。
パフォーマンス
アプリケーションの形が整うにつれ、パフォーマンスのボトルネック、特にネットワークに関連するあらゆるものに注意を払う必要があります。これは、多くの場合、モバイルウェブ アプリケーションの中で最も遅い部分です。
Web Components のポリフィルを条件付きで読み込むことで、パフォーマンスを簡単に向上させることができます。
プラットフォームがすでにフルサポートしていれば、このような費用をすべて負担する必要はありません。新しい webcomponents.js リポジトリの各リリースでは、ポリフィルも独立したファイルに分割されています。これは、ポリフィルのサブセットを条件付きで読み込む場合に便利です。
<script>
if ('import' in document.createElement('link')) {
// HTML Imports are supported
} else {
document.write(
'<script src="bower_components/webcomponentsjs/HTMLImports.min.js"><\/script>'
);
}
</script>
また、Svulcanize などのツールを使って HTML インポートのすべてを実行すると、ネットワークに大きなメリットがあります。
Sense はインポートを 1 つのバンドルに連結し、アプリが行う HTTP リクエストの数を大幅に削減します。
オフライン
しかし、高性能なアプリを構築しただけでは、接続がほとんどないかまったくないユーザーのジレンマは解決されません。つまり、オフラインで動作しないアプリはモバイルアプリとは言えません。現在は、極めて悪質なアプリ キャッシュを使用してリソースをオフラインにすることもできますが、将来的には Service Worker によってオフライン開発エクスペリエンスがまもなく改善されるはずです。
Jake Archibald は最近、Service Worker のパターンをまとめた優れたクックブックを発表しました。ここでは、これを簡単に使えるようにする方法について説明します。
Service Worker のインストールは簡単です。worker.js ファイルを作成し、アプリケーションの起動時に登録します。
worker.js をアプリケーションのルートに配置することが重要です。これにより、アプリの任意のパスからのリクエストをインターセプトできるようになります。
ワーカーのインストール ハンドラで、大量のリソース（アプリを実行するデータを含む）をキャッシュに保存しています。
これにより、ユーザーがオフラインでアプリにアクセスする場合に、少なくともフォールバック エクスペリエンスを提供できます。
次へ！
Web Components はウェブ プラットフォームに大きく追加されたアイテムですが、まだ黎明期にあります。ブラウザが増えるにつれ、アプリケーションを構築するためのベスト プラクティスを考案するのはデベロッパー コミュニティの責務です。上述の解決策は出発点として役立ちますが、学ぶべきことはまだたくさんあります。より良いアプリの構築に進みましょう。