devserverの自動リフレッシュ
3018 ワード
Webpackモジュールはファイルの傍受を担当し、Webpack-dev-serverモジュールはブラウザのリフレッシュを担当していることを知っています.この2つの原理について詳しく説明します.
ファイルリスニング
関連構成
さぎょうげんり
1つのファイルが変化したかどうかを傍受する原理は、このファイルの最後の編集時間をタイミングよく取得し、最新の最後の編集時間を多く保存するたびに、現在取得した最後の編集時間と最後に保存した最後の編集時間が一致しないことを発見した場合、そのファイルが変化したとみなすことである.
構成アイテムのwatchOptions.Pollはタイミングチェックの周期を制御するために用いられ、具体的には毎秒何回チェックするかを意味し、ファイルが変化したかどうかを判断することは、システムが指定したファイルに変化があるかどうかを尋ね続けることによって実現され、デフォルトでは毎秒1000回問い合わせる.
あるファイルが変化していることに気づいたら、すぐに監視員に話すのではなく、キャッシュしてしばらくの変化を収集した後、一度に傍受者に伝え、オプションwatchOptionsを構成します.AggregateTimeoutは、この待機時間を構成するために使用され、デフォルトは300 msです.このような目的は、私たちの高周波の入力文字が、ファイルの変化を招くことを防ぐために、高周波の発生を防ぐことです.
ignored:/node_modules/無視node_modulesの下のファイルは、傍受されません.これもファイルの傍受性能の最適化です.
リスニングの最適化 watchOptions.AggregateTimeoutの値が大きいほど性能が良い.これは再構成の周波数 を低減できるからである. watchOptions.pollの値が小さいほど良いのは、検査の頻度を低下させることができるため、 しかし,この2つの最適化法の結果は,リスニングモードの反応と感度の低下である.
ブラウザの自動更新
注意:webpack-dev-serverモジュールを使用してwebpackモジュールを起動すると、webpackモジュールのリスニングモードはデフォルトでオンになります.
じどうリフレッシュげんり
ブラウザのリフレッシュを制御するには、次の3つの方法があります.ブラウザ拡張によりブラウザが提供するインタフェースをリフレッシュし、webstormのliveEdit機能はこのように実現される. は、開発するウェブページにプロキシクライアントコードを注入し、プロキシクライアントを介してページ全体をリフレッシュする. 開発するウェブページをiframeに組み込み、iframeをリフレッシュすることで最新の効果を見る Webpackは2、3つ目の方法をサポートし、2つ目はdevserverがデフォルトで採用しているリフレッシュ方法です.
エージェントクライアントメソッドの欠陥
devserverをオンにします.inline構成項目の場合、devserverは出力されたchunk種ごとにエージェントクライアントのコードを注入し、私たちのプロジェクトが多くのchunkを出力する必要がある場合、構築が遅くなり、実際には自動リフレッシュを完了し、1ページはエージェントクライアントを必要とし、devserverのために各chunkに乱暴に注入します.あるページがどのchunkに依存しているのか分からないため、いっそすべてエージェントクライアントに注入され、ページはいずれかのchunkに依存すれば、エージェントクライアントはページに注入される.
iframeラベルの使用
優雅でないinlineモードをオフにして、エージェントクライアントを1つだけ注入することができます.この最適化方法は、上記とは異なります.入口URLはhttp://localhost:8080/になるhttp://localhost:8080/webpack-dev-server/; bundle.jsにはプロキシクライアントのコードが含まれなくなります.
本質は、リスニングが必要なページがiframeに格納され、ソースコードを編集するとiframeが自動的にリフレッシュされ、この最適化効果は出力するchunkの数が多ければ多いほど明らかになります.
その他
iframeでアクセスしたくないが、Webページを自動的にリフレッシュする機能を維持したい場合は、プロキシクライアントのスクリプトを手動でWebページに注入しindex.htmlに次のラベルを挿入します.
上記のスクリプトをWebページに注入すると、独立して開いたWebページは自動的にリフレッシュされますが、オンラインにパブリッシュするときに開発用のコードを削除することに注意してください.
ファイルリスニング
関連構成
module.export = {
// ,watchoptions
// false,
watch: true,
// ,watchOptions
watchOptions: {
ignored: /node_modules/,
aggregateTimeout: 300,
poll: 1000
}
}
さぎょうげんり
1つのファイルが変化したかどうかを傍受する原理は、このファイルの最後の編集時間をタイミングよく取得し、最新の最後の編集時間を多く保存するたびに、現在取得した最後の編集時間と最後に保存した最後の編集時間が一致しないことを発見した場合、そのファイルが変化したとみなすことである.
構成アイテムのwatchOptions.Pollはタイミングチェックの周期を制御するために用いられ、具体的には毎秒何回チェックするかを意味し、ファイルが変化したかどうかを判断することは、システムが指定したファイルに変化があるかどうかを尋ね続けることによって実現され、デフォルトでは毎秒1000回問い合わせる.
あるファイルが変化していることに気づいたら、すぐに監視員に話すのではなく、キャッシュしてしばらくの変化を収集した後、一度に傍受者に伝え、オプションwatchOptionsを構成します.AggregateTimeoutは、この待機時間を構成するために使用され、デフォルトは300 msです.このような目的は、私たちの高周波の入力文字が、ファイルの変化を招くことを防ぐために、高周波の発生を防ぐことです.
ignored:/node_modules/無視node_modulesの下のファイルは、傍受されません.これもファイルの傍受性能の最適化です.
リスニングの最適化
ブラウザの自動更新
注意:webpack-dev-serverモジュールを使用してwebpackモジュールを起動すると、webpackモジュールのリスニングモードはデフォルトでオンになります.
じどうリフレッシュげんり
ブラウザのリフレッシュを制御するには、次の3つの方法があります.
エージェントクライアントメソッドの欠陥
devserverをオンにします.inline構成項目の場合、devserverは出力されたchunk種ごとにエージェントクライアントのコードを注入し、私たちのプロジェクトが多くのchunkを出力する必要がある場合、構築が遅くなり、実際には自動リフレッシュを完了し、1ページはエージェントクライアントを必要とし、devserverのために各chunkに乱暴に注入します.あるページがどのchunkに依存しているのか分からないため、いっそすべてエージェントクライアントに注入され、ページはいずれかのchunkに依存すれば、エージェントクライアントはページに注入される.
iframeラベルの使用
優雅でないinlineモードをオフにして、エージェントクライアントを1つだけ注入することができます.この最適化方法は、上記とは異なります.
本質は、リスニングが必要なページがiframeに格納され、ソースコードを編集するとiframeが自動的にリフレッシュされ、この最適化効果は出力するchunkの数が多ければ多いほど明らかになります.
その他
iframeでアクセスしたくないが、Webページを自動的にリフレッシュする機能を維持したい場合は、プロキシクライアントのスクリプトを手動でWebページに注入しindex.htmlに次のラベルを挿入します.
<script src="http://localhost:8080/webpack-dev-server.js">script>
上記のスクリプトをWebページに注入すると、独立して開いたWebページは自動的にリフレッシュされますが、オンラインにパブリッシュするときに開発用のコードを削除することに注意してください.