webpack学習(四)—code spliting

何がcode splittingですか?
まず、code splittingとは何ですか?私たちは包装する時、大きなbundle.js(またはindex)のファイルを生成します.このように、すべてのモジュールはこのbundle.jsファイルに包装されます.最終的に作成されたファイルは比較的大きいです.code splittingとは、ファイルをブロックに分割すること(chunk)を意味し、webpackは、いくつかの分割点(split point)を定義し、これらの分割点に基づいてファイルをブロック化し、必要に応じてロードすることができるようにする.code splittingの意味

第三者クラスは単独で包装します.第三者クラスの内容は基本的に変わらないので、業務コードと分離してもいいです.そうすると、クラスコードをクライアントにキャッシュして、要求を減らすことができます.

は必要に応じてロードします.webpackは、定義された分割点をサポートし、require.ensureを介して必要に応じてロードする.

共通モジュールは単独で包装します.コードの中にはいくつかの汎用モジュールがあるかもしれません.例えば、パチンコ、改ページ、共通の方法などです.他の業務コードモジュールはしばしばこれらの共通モジュールを参照しています.2で行うと、共通モジュールが重複して包装されます.この時は共通モジュールを個別に包装してもいいです.

以下、詳細に説明する.
どうやってcode splitingを行いますか?
第三者クラス
私達のプロジェクトではよく第三のクラスの倉庫を使います.例えばjquery、bootstrapなどです.マルチエントランスを配置して、第三者のクラスを個別に包装してもいいです.以下の通りです.

// entry     
entry: {
    index: './index',
    vendor: ['jquery', 'bootstrap']
},

// plugins   
plugins: [
    new webpack.optimize.CommonsChunkPlugin("vendor", "vendor.bundle.js"),
]

説明CommonsChunkPluginは2つのパラメータを提供し、第1のパラメータは対応するchunk名(chunkはファイルブロック、entryに対応する属性名)、第2のパラメータは生成されたファイル名である.このプラグインは2つのことをしました.

は、vendorが構成するモジュール(jquery、bootstrap)をvendor.bundle.jsにラッピングする.

は、indexに存在するjqueryを、bootstrapモジュールをファイルから削除する.このようにindexには、純粋なトラヒックコードのみが残されている.

必要に応じてロードするbackboneに基づく単一ページアプリケーションを例にとると、routerにおいて構成が必要に応じてロードされ得る.

router.js

var Router = Backbone.Router.extend({
    routes: {
        'a': 'a',
        'b': 'b'
    },
    
    a: function() {
        require.ensure(['./a'], (require) => {
            let a = require('./a');
            //do something
        })
    },
    
    b: function() {
        require.ensure(['./b'], (require) => {
            let b = require('./b');
            //do something
        })
    }
})

上記のように、2つのファイルが表示され、a.jsとb.jsとが表示され、必要に応じてロードされます.aにアクセスするときだけ、a.jsはロードされ、bは同じ原理である.しかし、このやり方には二つの問題があります.

ルーティングの割り当てが不合理であれば、多くの小さなファイルが包装されます.各ファイルは数kしかないかもしれませんが、多くのネットワーク要求があります.

は、aモジュールおよびbモジュールがcモジュールを参照しているような、汎用モジュールの重複パッケージ化を引き起こすことがある.

a
import 'c' from './c'

b
import 'c' from './c'

このように、パッケージ化されたa.jsおよびb.jsの両方にcモジュールのコードが含まれており、コードの冗長性が生じることが分かります.
問題1については、webpackが提供するプラグインによって解決することができる.

// plugins      ：
plugins: [
    new webpack.optimize.AggressiveMergingPlugin()
]

問題2について:以下に説明するように解決することができる.
共通モジュール包装
この問題はネットで資料を調べましたが、特に良い案が見つかりませんでした.以下のように自分のためのいくつかの試みです.
同様にentryおよびcommonsChunkPluginを用いて処理される.以下のとおりです

// entry     
entry: {
    index: './index',
    common: ['./c', './d'],  //  c,d         
    vendor: ['jquery', 'bootstrap']
},

// plugin 
plugins: [
    new webpack.optimize.CommonsChunkPlugin(["common", "vendor"], "[name].js")  //[name]  'common' 'vendor'
]

このようにすればcommon.jsとvendor.jsの2つのファイルが包装される.commonは汎用機能モジュールである.
しかし、このような方式はプロジェクトが複雑に依存している場合の効果はあまり理想的ではなく、ある部分のコードを一回だけ読み込むことができません.もっといい案がある人は教えてください.
(本文は終わり)