フロントエンドリソースのロード再試行

紹介する
TO Cの応用に対して、ユーザーネットワークは千差万別で、いつも各種のネットワークの問題があって資源のロードに失敗して、アクセスする時に白いスクリーンが現れて、スタイルが乱れますなど.リソースのロード再試行は、ユーザー体験を向上させる上で重要な一環です.
最近,Vueの一連の技術体系を用いた開発が試みられている.Vueでリソースロードの再試行を行うにはどうすればいいですか?
しげんぶんるい
現在一般的なフロントエンドリソースは

scriptスクリプト

cssスタイルファイル

imgピクチャ

background-img背景図

webpack構築システムでは、ロード方式によって

htmlに内蔵script,linkラベル

imgピクチャ

import()またはrequire.Ensure非同期ロードのchunkは、webpack内蔵のローダで

を完了します.
実践案
インラインリソース再試行
assets-reload script, link, imgなどのラベル上のonerrorコールバックによってリソースロード再試行が行われ、置換されたURLルールがカスタマイズされる.背景図はスタイルシートを読み取るルールで、background-imgに一致すると、background-imgスタイルを再試行するために再挿入します.
具体的な実装は、このモジュールの参考をクリックしてください.
さらに,webpack構築自動化の能力に合わせて,これらのonerror関数をバインドした.
script
このモジュールにより,script-ext-html-webpack-pluginを再利用してscriptのonerror属性を構成する.

    new ScriptExtHtmlWebpackPlugin({
        custom: {
        test: /.js$/,
        attribute: 'onerror="attackCatch(this)"'
        }
    })

link
さらに、headに組み込まれたlinkラベルにonerrorのプロパティを追加する簡単なプラグインを書きます.

class MyPlugin {
  apply (compiler) {
    compiler.hooks.compilation.tap('css-attr-plugin', (compilation) => {
      compilation.hooks.htmlWebpackPluginAlterAssetTags
      .tapAsync('myPlugin', function (data, cb) {
        data.head.forEach(el=>{
          if(el.tagName === 'link'){
            el.attributes.onerror = 'attackCatch(this)';
          }
        })
        cb(null ,data);
      });
    })
  }
}

module.exports = MyPlugin

img
imgは現在、適切なプラグインが見つかりません.後で、対応するプラグインを自分で追加します.皆さんのお勧めも歓迎します
background-img背景図
バックグラウンドマップというブロックは、イベントリスニングがないため、全量置換しかできません.現在のアプリケーションは、ドメイン名をテストする環境でのみ、すべてのバックグラウンドマップリソースを現在のドメイン名に置き換えます.
Webpack内蔵非同期ローダ
webpack-plugin-import-retry webpackリソースローダ部分のコードを読み、ダウンローダ部分を書き換え、再試行を実現しました.また、入力フォーマットURL関数は、再試行時のリンクをカスタマイズするために使用されます.
ロードに失敗したchunkについて、再試行を行います.
1つのchunkは、JSおよびCSSリソースを含む場合があります.そのうちの1つのロードに失敗すると、1つのリソースが2回再試行されるまで失敗と判断されます.
リソースのロードを再試行することで、routerのうち、非同期のページファイルをロードした場合、失敗してホワイトスクリーンの問題を大幅に減らすことができます.

/******/     __webpack_require__.oldE = __webpack_require__.e;
/******/     __webpack_require__.e = function newRequireEnsure (chunkId, options) {
/******/                         return __webpack_require__.oldE(chunkId, options).then(function () {}, function (err) {
/******/                             console.error(err);
/******/                             var type;
/******/                             if (/.*.css??/.test(err.request)) {
/******/                                 type = 'LINK';
/******/                             } else if (/.*.js??.*/.test(err.request)) {
/******/                                 type = 'SCRIPT';
/******/                             }
/******/                             if (options === undefined) {
/******/                                 options = {
/******/                                     LINK: 0,
/******/                                     SCRIPT: 0
/******/                                 };
/******/                             }
/******/                             options[type]++;
/******/                             //     1
/******/                             if (options[type] <= 2) {
/******/                                 return newRequireEnsure(chunkId, options);
/******/                             }
/******/                         })
/******/                     }

ルールの再試行
私たちのプロジェクトでは、フロントエンドが配置したアーキテクチャは、フロントエンドプロジェクトファイルを自分の静的リソースサーバにパブリッシュするために、CDNはソースバック要求ファイルを実行します.
URLはドメイン名のみ異なり、パスは同じです.
したがって,我々の再試行規則はreloadAssets=1パラメータを加えて,何回目の再試行であるかを識別するために用いられる.
2回目の再試行では、CDNドメイン名を現在のドメイン名に置き換えます.
CDNドメイン名も不安定な場合があるので、CDNドメイン名を現在アクセスしているドメイン名に置き換えると、成功率が高くなります.
異なるトラフィックのCDNリソースをマスタリソースに置き換えるパスは必ずしも同じではないからである.したがって、カスタムルールはサポートされています.
ドメイン名アプリケーションのテスト
テスト環境では、アクセスのためにテストドメイン名を有効にします.
この場合、インクリメンタルファイルがCDNにパブリッシュされていないため、テストドメイン名にアクセスする際にインクリメンタルファイルが要求されず、そのためにインクリメンタルファイルをオンラインにパブリッシュするのは面倒です.
したがって、カスタムルールには、テスト環境であるかどうかの判断が追加され、テスト環境であれば、最初に再試行したときに現在のテストドメイン名に直接置き換えてアクセスします.
これにより、同じコードが異なるドメイン名に適しています.