ポリマーモジュールの加硫の使用

私が取り組んでいるプロジェクトには、ウィジェットのようなクライアントアーキテクチャがあります。 さらに、システムウィジェットは、ReactJS、PolymerJS、VueJS、d3JSなど、実装に任意のライブラリを使用できます。 PolymerJSに基づくWebコンポーネントのように、いくつかのシステムウィジェットが実装されています 。



したがって、ポリマーウィジェットを最適化する方法の1つに注目します。

---

内容：

1.問題の説明

2.どのような困難が生じますか？

3.どうすれば解決できますか？

4. vulcanize-polymer-moduleライブラリ

4.1。 構造

4.2。 bower.jsonの説明

4.3。 Package.jsonの説明

4.3.1。 ユーティリティのインストール

4.3.2。 RollupJSを構成する

4.4。 vulcanize-utils.js

5.結論

1.問題の説明

ポリマーアプリケーションの主な問題の1つは、使用済みコンポーネントとすべての依存コンポーネントの複数のロードです。これらのコンポーネントは、同じ方法でロードされる補助スタイルであるbehaviorで構成されます。 その結果、ネットワークセクションのコンソールはこれらのファイルで「爆撃」されます。 これらすべてを考慮すると、使用する複合Webコンポーネントの数によっては、このようなウィジェットの最初のダウンロードに非常に時間がかかる場合があります。



これらの目的のために、ポリマー用途は加硫を使用します。 このアプリケーションには、 index.htmlなどの形式のエントリポイントがあり、その中に<App />などのメインコンテナコンポーネントがデプロイされていることがわかります。 このファイルでは、ポリマーコア自体とコンテナコンポーネントファイル<App />が接続され、その後、それ自体が個別のhtmlファイルである使用済みコンポーネントがすべて階層的に接続されます。 加硫プロセス自体は、すべての使用済みコンポーネントとポリマーコアを1つのファイルに「接着」することで構成され、最終的にはindex.htmlのエントリポイントになります。

2.どのような困難が生じますか？

1. 最初の難しさは、ポリマーアプリケーションではなく、システムウィジェットにラップされた複数の複合コンポーネント（スマートコンポーネント-CCと呼びましょう）、つまり単一のエントリポイントがないことです。
2. 2番目の難点は、アプリケーションの操作中にこれらのウィジェットを含むページがまったく呼び出されない可能性があることです。したがって、現在のセッションでは、ポリマーコア自体は言うまでもなく、ポリマーコンポーネントは一切必要ありません。
3. 第三に 、1つのCCはアトミック（ 紙 、 鉄など）コンポーネントの1つのセット（それらを愚かなコンポーネント-GKと呼びましょう）を使用し、もう1つは別のセットを使用します。 さらに、交差点がある可能性があります。つまり、2つの異なるUKが同じHAを使用しています。

3.どうすれば解決できますか？

最初の複雑さを考慮すれば、各英国を個別に加硫できますが、3番目の問題をとると、同じHAの複製が可能になり、1回のセッションで少なくとも2つの英国が使用される状況を考慮すると、ポリマーコアの複製が必ず存在します。 したがって、別のソリューションが必要です。



2番目の複雑さを考慮する場合、最初にCCの 1つにアクセスするときにポリマーコアとGKが一度だけロードされることを確認する必要があり、2番目にアクセスするときに、すべてを再度ダウンロードする必要はなく、 CC自体を動的にロードするだけです

3番目の複雑さを考慮する場合、スマートコンポーネントで使用されるすべての愚かなコンポーネントのリストを作成する必要があり、最終的にはポリマー自体と一緒に加硫します。

4. vulcanize-polymer-moduleライブラリ

上記の論文はすべて、加硫ポリマーモジュールライブラリの形で設計しました。

それについてもっとお話ししたいと思います。

4.1。 構造

vulcanize-polymer-module/

├── imports.html

├── vulcanize-utils.js

├── rollup.config.js

├── bower.json

└── package.json

4.2。 bower.jsonの説明

その中で、ポリマーコア自体を含む、依存関係として必要なすべてのGCについて説明します。



たとえば、 依存関係セクションは次のようになります。





私はポリマーでreduxを使用しているため、 polymer-reduxライブラリを含めました。

4.3。 Package.jsonの説明

これには、ビルドする必要のある依存関係、特に出力ファイルコードの中間クリーニングに使用されるRollupJSが含まれています。 加硫に使用されるコマンドについても説明します。詳しく見てみましょう。





チーム、使用の順序と優先順位：

• build-allは、加硫プロセス全体を開始するメインチームです。
• vulcanized-加硫自体 、つまりすべてのコンポーネントとカーネルを1つのファイルに結合し、アセンブリ全体を.jsファイルと.htmlファイルに個別に分割します（ユーティリティvulcanizeとcrisperが使用されます ）
• build -js-fileコードをコメントから削除 （ RollupJSを使用）
• html-minifier -htmlファイルの縮小（ html-minifierを使用）

4.3.1。 ユーティリティのインストール

ご覧のとおり、多くの追加ユーティリティが使用されています。これらのユーティリティを最初にシステムにインストールする必要があります。

4.3.2。 RollupJSを構成する

ロールアップはjsコードをクリーンアップするためにのみ使用されるため、 ロールアップ用に1つのプラグイン、 rollup-plugin-cleanupのみを使用します。 rollup-plugin-progressプラグインは 、ビルドプロセスを視覚化するために使用されます。

4.4。 vulcanize-utils.js

2番目の要件を解決するために、実用的なメソッドloadVulcanizedが作成されました。これはUKをロードしますが、その前に加硫されたファイルをダウンロードし、1回実行します。繰り返し呼び出しの場合は、 UKのみをロードします。

そのパラメーターをさらに詳しく考えてみましょう。

5.結論

もちろん、 build -cliでPolymer-cliを使用できますが、それをアセンブルすると、polymerプロジェクトがビルドされていることがわかります。複数の<App />コンテナーでコンポーネントを使用するため、各CCを個別に収集する必要があり、アセンブリファイルはポリマーコアと複合HAが重複しています。 したがって、この記事で説明されているアプローチは、ポリマーに基づくすべてのCCの単一のエントリポイントにより、複数のUIライブラリを一緒に使用するシステムで非常に効果的です。



可能性のある欠点の1つは、システムで使用されるすべてのACのすべてのGAを含むが、作業セッション中にすべてのACを使用できるわけではないため、加硫ファイル内のHAの冗長性と考えることができます。加硫ファイルをアップロードしました。



また、少し不便なことに、新しいコンポーネントを追加した後、アセンブリを再起動し、リポジトリを更新（プッシュ）する必要があり、他のユーザーはbower updateでこのライブラリを更新する必要があるという事実を考慮することができます。



このすべてにもかかわらず、このライブラリはこのプロジェクトの問題を解決します。つまり、他の誰かにとって有用である可能性があります。



フォーク 、ようこそ。