モノリスをどのように見たか。パート3、フレームなしのフレームマネージャー

ねえ。では最後の記事、フロントエンドアプリケーションのオーケストレーター- Iは、フレームマネージャについて話しました。説明されている実装は多くの問題を解決しますが、欠点があります。



アプリケーションがiframeにロードされるため、レイアウトに問題が発生し、プラグインが正しく機能せず、アプリケーションとフレームマネージャーのAngularのバージョンが同じであっても、クライアントはAngularで2つのバンドルをダウンロードします。そして、2020年にiframeを使用することは悪いマナーのようです。しかし、フレームをあきらめて、すべてのアプリケーションを1つのウィンドウにロードするとどうなるでしょうか。



これが可能であることが判明したので、次にそれを実装する方法を説明します。

可能な解決策

シングルスパ：「フロントエンドマイクロサービス用のjavascriptルーター」-ライブラリのWebサイトに示されています。異なるフレームワークで記述されたアプリケーションを同じページで同時に実行できます。このソリューションは機能しませんでした。ほとんどの機能は必要ありませんでした。また、System.jsローダーを使用すると、Webpackを使用してビルドするときに問題が発生する場合があります。また、webpackでモジュールローダーを使用することは最善の解決策ではないようです。



Angular要素：このパッケージを使用すると、AngularコンポーネントをWebコンポーネントでラップできます。アプリケーション全体をラップできます。次に、古いブラウザ用にポリフィルを追加する必要があります。独自のルーティングを使用してアプリケーション全体からWebコンポーネントを作成することは、イデオロギー的に間違った決定のように見えます。

フレームマネージャーの実装

例を使用して、フレームマネージャでフレームなしでアプリケーションをロードする方法を見てみましょう。



初期設定は次のようになります。メインアプリケーション-mainがあります。常に最初にロードされ、それ自体の中に他のアプリケーション（app-1およびapp-2）をロードする必要があります。ng new <app-name>コマンドを使用して3つのアプリケーションを作成しましょう。次は、ようにプロキシの設定に必要なアプリケーションのHTMLとJSファイルがされているフォームの要求に送ら/<app-name>/*.js、/<app-name>/*.html、およびメインアプリケーションの静力学は、他のすべての要求に送信されます。





アプリケーションapp-1およびapp-2の場合、それぞれ、angular.jsonapp1およびapp2でbaseHrefを指定します。また、ルートコンポーネントセレクターをapp-1とapp-2に変更します。





まず、少なくとも1つのサブアプリケーションをロードしましょう。これを行うには、index.htmlで指定されているすべてのjsファイルをロードする必要があります。



jsファイルのURLを確認します。index.htmlのhttpリクエストを作成し、DOMParserを使用して文字列を解析し、すべてのスクリプトタグを選択します。すべてを配列に変換して、アドレスの配列にマップしましょう。この方法で取得したアドレスにはlocation.originが含まれるため、空の文字列に置き換えます。

private getAppHTML(): Observable<string> {
  return this.http.get(`/${this.currentApp}/index.html`, {responseType: 'text'});
}

private getScriptUrls(html: string): string[] {
  const appDocument: Document = new DOMParser().parseFromString(html, 'text/html');
  const scriptElements = appDocument.querySelectorAll('script');

  return Array.from(scriptElements)
    .map(({src}) => src.replace(this.document.location.origin, ''));
}

アドレスがあります。スクリプトをロードする必要があります。

private importJs(url: string): Observable<void> {
  return new Observable(sub => {
    const script = this.document.createElement('script');

    script.src = url;
    script.onload = () => {
      this.document.head.removeChild(script);

      sub.next();
      sub.complete();
    };
    script.onerror = e => {
      sub.error(e);
    };

    this.document.head.appendChild(script);
  });
}

コードは、必要なsrcを含むスクリプト要素をDOMに追加し、スクリプトをダウンロードした後、これらの要素を削除します。これはかなり標準的なソリューションであり、webpackとsystem.jsへのロードも同様に実装されます。



スクリプトをロードした後（理論的には）、組み込みアプリケーションを起動するためのすべてが揃っています。しかし実際には、メインアプリケーションの再初期化を取得します。ロードされたアプリがメインのアプリと何らかの形で競合しているようですが、iframeにロードされたときに発生しませんでした。

Webパックバンドルの読み込み

Angularはwebpackを使用してモジュールをロードします。標準構成では、Webpackはコードを次のバンドルに分割します。

• main.js-すべてのクライアントコード。
• polyfills.js-ポリフィル;
• styles.js-スタイル;
• vendor.js-Angularを含む、アプリケーションで使用されるすべてのライブラリ。
• runtime.js-webpackランタイム;
• <module-name> .module.js-レイジーモジュール。

これらのファイルのいずれかを開くと、最初に次のコードが表示されます。

(window["webpackJsonp"] = window["webpackJsonp"] || []).push([/.../])

そしてruntime.jsでは：

var jsonpArray = window["webpackJsonp"] = window["webpackJsonp"] || [];
jsonpArray.push = webpackJsonpCallback;
jsonpArray = jsonpArray.slice();
for(var i = 0; i < jsonpArray.length; i++) webpackJsonpCallback(jsonpArray[i]);

これは次のように機能します。バンドルがロードされると、配列webpackJsonpがまだ存在しない場合は作成され、その内容がバンドルにプッシュされます。webpackランタイムは、この配列のプッシュ機能をオーバーライドして、後で新しいバンドルをアップロードできるようにし、配列に既に存在するすべてのものを処理します。



バンドルがロードされる順序が重要にならないように、これはすべて必要です。



したがって、2番目のAngularアプリケーションをロードすると、そのモジュールを既存のWebpackランタイムに追加しようとします。これにより、せいぜいメインアプリケーションが再初期化されます。

webpackJsonpの名前を変更します

競合を回避するには、webpackJsonp配列の名前を変更する必要があります。 Angular CLIは独自のwebpack構成を使用しますが、必要に応じて拡張できます。これを行うには、angular-builders / custom-webpackパッケージをインストールする必要があります：



npm i -D @ angle-builders / custom-webpack。



次に、プロジェクト構成のangular.jsonファイルで、architect.build.builderを@ angle-builders / custom-webpack：browserに置き換え、architect.build.options：に追加します。

"customWebpackConfig": {
  "path": "./custom-webpack.config.js"
}

また、これをdevサーバーとローカルで機能させるには、architect.serve.builderを@ angle-builders / custom-webpack：dev-serverに置き換える必要があります。



次に、上記のcustomWebpackConfigで指定されているWebpack構成ファイルを作成する必要があります。custom -webpack.config.js



カスタム設定を定義します。詳細については、公式ドキュメントを参照してください。jsonpFunctionに



興味があります。



ロードされたすべてのアプリケーションでこのような構成を設定して、競合を回避できます（その後も競合が残っている場合は、呪われている可能性があります）。

module.exports = {
 output: {
   jsonpFunction: Math.random().toString()
 },
};

ここで、上記の方法ですべてのスクリプトをロードしようとすると、エラーが表示されます。







アプリケーションをロードする前に、そのルート要素をDOMに追加する必要があります。

private addAppRootElement(appName: string) {  
  const rootElementSelector = APP_CFG[appName].rootElement;
  this.appRootElement = this.document.createElement(rootElementSelector);
  this.appContainer.nativeElement.appendChild(this.appRootElement);
}

もう一度試してみましょう-万歳、アプリケーションがロードされました！

アプリケーションを切り替える

以前のアプリケーションをDOMから削除し、アプリケーションを切り替えることができます。

destroyApp () {
  if (!this.currentApp) return;
  this.appContainer.nativeElement.removeChild(this.appRootElement);
}

ただし、ここには欠陥があります。app-1→app-2→app-1に移動すると、app-1アプリケーションのjsバンドルをリロードし、それらのコードを実行します。さらに、以前にロードされたアプリケーションを破棄しないため、メモリリークや不要なリソース消費が発生します。



アプリケーションバンドルを再ダウンロードしない場合、ブートストラッププロセスはそれ自体では実行されず、アプリケーションはロードされません。ブートストラップ起動プロセスをメインアプリケーションに委任する必要があります。



これを行うには、ロードされたアプリケーションのmain.tsファイルを書き直してみましょう。

const BOOTSTRAP_FN_NAME = 'ngBootstrap';
const bootstrapFn = (opts?) => platformBrowserDynamic().bootstrapModule(AppModule, opts);

window[BOOTSTRAP_FN_NAME] = bootstrapFn;

bootstrapModule メソッドはすぐには実行されませんが、グローバル変数にあるラッパー関数に格納されます。メインアプリケーションでは、それにアクセスして、必要に応じて実行できます。



アプリケーションを破棄してメモリリークを修正するには、ルートアプリケーションモジュール（AppModule）のdestroyメソッドを呼び出します。 platformBrowserDynamic（）。BootstrapModuleメソッドは、それにリンクを返します。これは、ラッパー関数を意味します。

this.getBootstrapFn$().subscribe((bootstrapFn: BootstrapFn) => {
  this.zone.runOutsideAngular(() => {
    bootstrapFn().then(m => {
      this.ngModule = m;  //    
    });
  });
});

this.ngModule.destroy(); //   

ルートモジュールでdestroy（）を呼び出した後、すべてのサービスおよびアプリケーションコンポーネント（実装されている場合）のngOnDestroy（）メソッドが呼び出されます。



すべてが機能します。ただし、ロードされたアプリケーションに遅延モジュールが含まれている場合、それらはロードできません。







アドレスにアプリケーションパスがないことがわかります（/app2/lazy-lazy-module.jsがあるはずです）。この問題を解決するには、メインアプリケーションとロードされたアプリケーションのベースhrefを同期する必要があります。

private syncBaseHref(appBaseHref: string) {
  const base = this.document.querySelector('base');

  base.href = appBaseHref;
}

これで、すべてが正常に機能します。

結果

メインアプリケーションにスクリプトをロードする前にconsole.time（）を配置し、メインアプリケーションのルートコンポーネントのコンストラクターにconsole.timeEnd（）を配置して、サブアプリケーションのロードにかかる時間を見てみましょう。



app-1およびapp-2アプリケーションが初めてロードされると、次のようなものが表示され







ます。かなり高速です。ただし、以前にダウンロードしたアプリケーションに戻ると、次の番号が表示







されます。必要なすべてのチャンクがすでにメモリにあるため、アプリケーションは即座にロードされます。ただし、アプリケーションが破棄された場合でも、メモリリークが発生する可能性があるため、未使用のオブジェクト参照とサブスクリプションにはさらに注意する必要があります。

フレームなしのフレームマネージャー

上記のソリューションは、iframeの有無にかかわらずアプリケーションのロードをサポートするフレームマネージャーに実装されています。Tinkoff Businessのすべてのアプリケーションの約4分の1がフレームなしでロードされ、その数は絶えず増加しています。



また、説明したソリューションのおかげで、Angularと、フレームマネージャーおよびアプリケーションで使用される一般的なライブラリを操作する方法を学びました。これにより、読み込みと作業の速度がさらに向上しました。これについては次の記事で説明します。



サンプルコードのあるリポジトリ