昨年、Polymer のチームは、独自の要素の作成方法をデベロッパーに教えるために多くの時間を費やしてきました。その結果、Polymer の Core と Paper の要素、そして Mozilla のチームが作成した Brick 要素が大部分を支え、急速に成長するエコシステムが形成されました。
デベロッパーが独自の要素の作成に慣れ、アプリケーションの構築について考えるようになると、次のような疑問が生じます。
- アプリの UI をどのように構造化すればよいですか。
- どのように遷移するか。
- パフォーマンスを高めるための戦略
- オフライン体験をどのように提供すればよいのでしょうか。
Chrome Dev Summit では、小規模な連絡先アプリケーションを構築し、その構築プロセスを分析することで、これらの質問に答えようとしました。次のような結果が出ました。
構造
アプリケーションを複数のモジュールに分割して組み合わせて再利用できるようにすることは、Web Components の中心的なテナントです。Polymer の core-* と paper-* の要素を使用すると、core-ツールバーや paper-icon-button などの小さな要素から簡単に開始できます。
...そして、合成の力を通じて、それらを任意の数の要素と組み合わせて、アプリケーションのスキャフォールドを作成します。
汎用のスキャフォールドを配置したら、独自の CSS スタイルを適用して、ブランド独自のエクスペリエンスに変換できます。コンポーネントを使用してこれを行う利点は、同じアプリ構築のプリミティブを活用しながら、まったく異なるエクスペリエンスを作成できることです。足場を確立したら、コンテンツについての検討に移ります。
多くのコンテンツを処理するのに適した要素の 1 つが core-list です。
core-list はデータソース（基本的にはオブジェクトの配列）に接続でき、配列内の各アイテムに対してテンプレート インスタンスがスタンプされます。テンプレート内では、Polymer のデータ バインディング システムの機能を活用して、コンテンツをすばやく結合できます。
切り替え効果
アプリのさまざまなセクションを設計、実装したら、次のタスクは、セクション間を実際に移動する方法を見つけることです。
core-animated-pages はまだ試験運用版の要素ですが、アプリのさまざまな状態間の遷移に使用できるプラグイン可能なアニメーション システムを提供します。
しかし、アニメーションはパズルの半分にすぎません。アプリケーションでこれらのアニメーションとルーターを組み合わせて URL を適切に管理する必要があります。
ウェブ コンポーネントのルーティングには、命令型と宣言型の 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>
また、Vulcanize などのツールを使用してすべての HTML Import を実行することで、ネットワークが大幅に向上します。
Vulcanize は、インポートを 1 つのバンドルに連結して、アプリが実行する HTTP リクエストの数を大幅に削減します。
オフライン
しかし、高パフォーマンスのアプリを作成するだけでは、接続がほとんど、またはまったくないユーザーが抱えるジレンマは解消されません。つまり、アプリがオフラインで動作しない場合、そのアプリは実際にはモバイルアプリではありません。現在は、大幅に調整されたアプリケーション キャッシュを使用してリソースをオフラインにできますが、将来的には Service Worker によってオフラインでの開発エクスペリエンスが大幅に改善されるはずです。
Jake Archibald が最近、Service Worker のパターンをまとめた素晴らしいクックブックを公開しました。ここでは簡単に始めてみましょう。
Service Worker のインストールは簡単に終了します。worker.js ファイルを作成し、アプリケーションの起動時に登録します。
worker.js をアプリケーションのルートに配置することが重要です。これにより、アプリ内の任意のパスからのリクエストをインターセプトできるようになります。
ワーカーのインストール ハンドラで、大量のリソース（アプリの基盤になるデータを含む）をキャッシュに保存します。
これにより、アプリがオフラインでアクセスする場合、少なくとも代替機能をユーザーに提供できます。
次へ！
ウェブ コンポーネントはウェブ プラットフォームに加わった大きな要素であり、まだ初期段階にあります。使用するブラウザが増えれば、アプリケーションを構成するためのベスト プラクティスを見つけ出すのは、私たちデベロッパー コミュニティ次第です。上記の解決策は出発点として利用できますが、学ぶべきことはまだたくさんあります。より優れたアプリの構築に取り掛かりましょう。