目次
ソースコードが変更された後、ブラウザーはいつ再コンパイルされたリソースを取得する必要がありますか?
ビルド システムのサポートにより、フロントエンドの開発者は、ソース コード作成の開発と保守に役立つ多くの手法を使用できます。ただし、開発プロセス中にソース コードを変更するたびに、ブラウザーでデバッグする前にビルドが必要になると、明らかに作業効率に大きく影響します。この問題を解決するために、ローカル開発サーバーをビルド システムと組み合わせて、ソース コードを監視し、変更後に動的ビルドをトリガーして、手作業を自動的に置き換えることができます。さらに、ビルドシステムはソースコードを本番環境で使用できるファイルに変換し、主に開発レベルの問題を解決します。Web 開発プロセスでは、開発レベルの問題だけでなく、コラボレーションも作業効率を左右する重要な要素であり、最も典型的なのは、フロントエンドのロジックがサーバー側の非同期インターフェイスの完成に依存するシリアル ワークフローです。ローカル開発サーバーのもう 1 つの主な機能は、フロントエンドとバックエンドの並行開発を実現するためのモック サービスを提供することです。
ローカル開発サーバーによって解決された問題
ローカル開発サーバーの主な機能は動的構築とモックサービスです。動的構築によって解決される問題は、開発レベル向けであり、監視→修正→トリガー→ビルドというプロセスにより、ソースコードを修正するたびに手動でビルドを実行する必要がなくなり、リアルタイムのデバッグに便利です。開発プロセス中。モック サービスによって解決される問題は、フロントエンドとバックエンドのコラボレーション レベルに向けられています. 事前に合意された仕様を前提として、ローカル サービス コンテナーによって提供されるモック データ インターフェイスは、フロントエンド ロジックの記述を支援します. また、SSR（サーバーサイドレンダリング）が必要なプロジェクトの場合、ローカル開発サーバーにもHTMLテンプレートをパースする機能が必要で、MockサービスはSSRに必要な初期データを提供します。
動的構造
動的構築の必要性は、開発中のフロントエンド エンジニアによるリアルタイム デバッグを容易にすることです。動的な構築シナリオのない開発プロセスを想像してみましょう。
[1]フロントエンドエンジニアは、ソースコードを書いた後、ビルド出力対象ファイルを手動で実行し、ブラウザで効果を確認します。
[2] 対象ファイルをブラウザで実行した際、特定のCSSプロパティに問題があることが判明。
【3】エンジニアはブラウザのデバッグパネルで問題を修正し、修正したコードをソースコードに書き込んで、ビルドを実行した後に再度ブラウザを開いてその効果を確認しました。
【4】しかし、ビルド後のターゲットファイルにはまだ問題があり、エンジニアはデバッグ→ソースコード修正→手動ビルド→デバッグの作業を繰り返さなければなりません。
フロントエンドの開発プロセスでは、特に CSS 効果の実現のために頻繁にデバッグを行う必要があり、ソース コードを変更するたびに手動でビルドを実行すると、必然的に作業効率が低下します。動的構築の役割は、自動構築によって手作業を置き換え、開発以外のフロントエンドエンジニアのエネルギー消費を削減することです。ホスト環境に認識されないソースコードを実行可能なコードに加工する加工機に例えると、動的構築はソースコードと加工機をつなぐパイプラインです。このパイプラインには、モニタリングとトリガーという 2 つの機能モジュールがあります。パイプラインのオープン中に、ソースコードの変更が監視モジュールによって検出され、トリガーモジュールがこの処理マシンの構成を起動して、変更されたソースコードを処理します。
モックサービス
動的な構築により、フロントエンドエンジニアが一方的に開発するのに便利. モックサービスは、フロントエンドおよびフロントエンド開発者を対象としています. コラボレーションプロセス中、フロントエンドロジック開発の一部は、サーバーの完成に基づいている必要があります. -チーム全体の開発サイクルを 2 倍にする側のデータ インターフェイス。フロントエンドエンジニアは、ローカルサーバーが提供するモックデータインターフェースを使用して、サーバーサイドの開発と並行してフロントエンドロジックを開発し、サーバーサイドインターフェースの開発が完了すると、インターフェースのリクエストアドレスはMock サービスからサーバー側環境に移行しました。Mock サービスが機能するために必要な前提条件は、フロントエンド開発者とバックエンド開発者が正式に開発に入る前にデータ インターフェイスの仕様を交渉することであり、これは技術的な問題だけではありません。前の章で、フロントエンドエンジニアリングシステムには技術サポートだけでなく、人事コミュニケーションの仕様も必要であることを述べました。
プロジェクトがフロントエンドとバックエンドから完全に分離されていない場合でも、HTML をレンダリングするためにサーバーに依存する必要があり、ローカル開発サーバーがサーバーと同じプログラミング言語を使用している場合、Mock サービスにも SSR が必要です。次の 2 点を含む機能。【1】サーバーサイドと同じHTMLテンプレートエンジンに対応。【2】SSRで必要なモックデータ。
まとめると、モックサービスは公式サーバーの代替に相当しますが、フロントエンドに必要な基本的な機能（非同期インターフェースとSSR）と、フロントエンドロジックとは関係のない機能しかありません（ (データベース操作、キャッシュレイヤー、セッション管理など) Mock サービスの範囲外です。ビルド システムと比較すると、ローカル開発サーバーが対処する問題は非常に明確です。
動的構造
動的構築、または動的コンパイル (動的コンパイル) は Self 言語に由来し、このテクノロジの最も広く知られている用途は Java です。フロントエンド エンジニアリング システムでのいわゆる動的コンパイルは、Java での同名の概念と同じではありません.Java に適用される最も一般的な動的コンパイルは、コンパイルを遅らせるジャスト イン タイム コンパイル (JIT) です。ランタイム実行に対する一部のコードの動作. 目的は、パフォーマンスを向上させることです. ここで説明する動的コンパイルはそれほど複雑ではありません.前述のように、ローカル開発サーバーの動的コンパイル機能の目的は、省力化とフロントエンド開発およびデバッグの容易化です.本質的な原則は監視+トリガーです. webpack-dev-server は、ローカル開発環境を構築するために公式に提供されている micro-node.js サービス フレームワークであり、動的コンパイル、HMR (ホット アップデート) などの機能を提供します。プロジェクトが Mock サービスを必要としない場合、webpack-dev-server は要件を完全に満たすことができます。ただし、Mock サービスは、ローカル開発サーバーの不可欠な機能であり、最も重要な機能であり、破棄することはできません。幸い、webpack には、Express フレームワークのミドルウェアである webpack-dev-middleware も用意されており、必要な機能モジュールと組み合わせることで、動的コンパイルやホット アップデートなどの機能を実現できます。
ソースコードが変更された後、ブラウザーはいつ再コンパイルされたリソースを取得する必要がありますか?
これは当然の質問のように思えるかもしれませんが、あなたは何も考えずに答えるかもしれません: もちろん、再コンパイルが完了した後です。では、再コンパイルが完了したことをどのように知るのでしょうか? 出力コンパイルのログを取得するまで、コマンド ライン ウィンドウを見つめ続けますか? フロントエンドエンジニアリングシステムの原則の1つは、自動化できる作業は人手を消費しないというものですが、この手動の「追跡」方法は明らかにこの原則に違反しています。webpack がリリースされる前は、業界のほとんどのツールは、動的コンパイルが完了した直後にブラウザーを自動的に更新するようにトリガーすることでこの問題を解決し、ブラウザーが再コンパイルされたリソースを時間内に取得できるようにしていました. この解決策は Livereload と呼ばれています. webpack は、より効率的でデバッグしやすいソリューションを使用しています: ホットモジュール交換、または略して HMR です。次に、Livereload と HMR の違いと、HMR と Livereload をローカル開発サーバーに統合して、ブラウザーが動的コンパイルリソースをリアルタイムで取得できるようにする方法について説明します。
Livereload と HMR
ライブリロード
Livereload の原理は, ブラウザーとサーバー (ローカル開発サーバー) の間にWebSocket 接続を作成することです. サーバーは動的コンパイルを実行した後にブラウザーに reload イベントを送信し、ブラウザーはイベントを受信した後にページ全体を更新します. プロセス図ショーに示されています。
Livereload は、動的に構築されたリソースがブラウザーによって即座に取得されることを保証できますが、致命的な欠陥があります: ページの状態を保存できません。たとえば、CSS にはロジックがまったくないため、デバッグは CSS を記述する上で最も重要な部分であり、熟練した CSS 開発者でさえ、デバッグなしで記述された CSS がブラウザーで期待される効果を発揮することを保証することはできません。そのため、ほとんどの CSS 作成作業は、最初にブラウザーのデバッグ パネルで効果を確認してから、コードをソース ファイルに書き込むことになります。さらに、複雑な CSS 効果は、単一の HTML 要素では実現できない場合があり、多くの場合、複数の要素の連携を必要とする包括的なソリューションです。次に、次のシナリオを想像してください。
【1】複雑な CSS 効果はブラウザのデバッグ パネルを介して実現され、含まれる HTML 要素の数は 5 です。
[2] CSS コードをソース ファイルに書き込む過程で、4 番目の要素の CSS コードを書き込んだ後に誤ってソース ファイルを保存したり、単純に要素のコードを省略したりしています。
【3】ソースファイルを修正・保存した直後に動的ビルドを行い、ビルド完了後に Livereload を行います。
[4]ページを更新した後、要素の CSS コードがソース ファイルにないため、UI が混乱する。
上記のシナリオが発生する理由は 2 つあります. 1 つは、ブラウザーのデバッグ パネルのコードが一時的なものであり、ページが更新されると消去されることです. もう 1 つは、開発者が不注意であることです. ヒューマンエラーは完全に回避できると言っても過言ではありませんが、実際の開発では、この「低レベルのエラー」が作業効率を大きく左右する要因の1つです。フロントエンドエンジニアリングシステムを確立する理由の1つは、開発段階である程度のフォールトトレランスを確保し、出力段階で品質を厳密に管理することです。したがって、エンジニアリングシステムの各機能モジュールの構築中に、ヒューマンエラーは技術レベル外の要因であるため、エンジニアリング効率への影響を無視することはできません。
ヒューマンエラーを考慮しなくても、Livereload は複雑な操作プロセスを表示する必要がある一部のコンポーネントにも影響を与えます。たとえば、ポップアップ ウィンドウ コンポーネントを表示するには、3 つまたは 4 つのステップで操作する必要があります。HMR は、ページ全体の更新を部分的な更新に置き換えます。これにより、Livereload がページの状態を保存できないという欠点が効果的に補われます。
HMR
HMR ワークフロー webpack-dev-server モードがオンになっている場合、webpack は追加の機能モジュールをビルドの出力ファイルに挿入します - HMR ランタイム。同時に、対応するサービス モジュールである HMR サーバーもサーバーに挿入されます。The two are the relationship between the client and the server. Livereload の実装と同様に、2 つの間の通信も WebSocket を介して行われます。HMR ホット アップデートのプロセスを図に示します。
[1] ソース ファイルを変更して保存した後、webpack はファイルシステム イベントをリッスンし、再構築動作をトリガーします。
[2] 構築が完了すると、webpack はモジュールの変更情報を HMR サーバーに渡します。
[3] HMR サーバーは WebSocket を介してプッシュ メッセージを送信し、クライアント モジュールを更新する必要があることを HMR ランタイムに通知します。次に、HMR ランタイムは更新するモジュールのコンテンツの詳細を HTTP を介して取得します。
【4】最終的に、HMR ランタイムは更新されたモジュールを置き換え、ブラウザはプロセス中に更新されません。
上記のプロセスは非常に明確に見えますが、HMR サーバーが情報をランタイムに渡すファイルの形式、ランタイムがモジュールのコンテンツを置き換えてすぐに有効になる方法など、味わう価値のある多くの技術的な詳細があります。これには、webpack の内部の詳細とブラウザーの原理に関するある程度の知識が必要です。関連情報を自分で確認できます。
Express 統合 HMR 機能
webpack-hot-middleware は、Express サーバー側統合に使用される HMR を実現できるミドルウェアです.統合方法は非常に簡単で、webpack-dev-middleware の後に HMR ミドルウェアにアクセスするだけです.