jsファイルキャッシュのバージョン管理を詳しく解説

ここ数か月の作業は取引システムの継続的な改善プロジェクトであり、反復的なリリースサイクルは約 2 ～ 3 週間です。最新版は水曜日にリリースされた V16 バージョンです。残念なことに、彼は翌朝ボスに捕まりました。上司が本番環境でバグを発見したことが判明しました。一般的な問題は次のとおりです。

システムには顧客の選択を支援するために一般的に使用されるカスタムコントロールがあり、V16 バージョンの継続的な改善要件は、さまざまなデフォルト値構成をサポートするためにコントロールに 2 つのフィルタリングオプションを追加することです。これは非常に単純な要件であり、コードの変更も簡単です。変更の 1 つは、構成値を渡すために、受信パラメーターを js ファイル内の関数に追加することです。 RC および RTW テストの後は、すべてが正常に見えましたが、バグは本番環境に導入されて初めて発見されました。読み込まれた顧客は明らかに異常で、数値が間違っており、予想されるクエリ構成と一致しません。

コントロールの内部ジャンプリンクを確認し、渡されたパラメータが明らかに期待と矛盾しています。このリンクは上記で変更された JS 関数によって生成されています。したがって、クライアントが元の JS ファイルをキャッシュし、新しい関数の呼び出しが古い関数に置き換えられることが問題の原因であると判断されます。キャッシュをクリアしてページを再ロードすると、このカスタムコントロールは正常に動作できるようになります。残念ながら、すべてのユーザーに電話して、この機能を使用する前にキャッシュをクリアする必要があることを伝えることはできません。

この時点で、JS のキャッシュの問題を制御する方法が必要であることに気付きました。そうしないと、キャッシュが最新の JS ファイルを取得できないため、JS ファイルの内容に関わる後続の変更が本番環境での事故を引き起こす可能性があります。

原則として、JS ファイルを毎回リロードするのではなく、JS ファイルをリロードする必要があります。したがって、最初のアプローチは、JS アプリケーションのアドレスの後にランダムなパラメータを追加することを意味するため、お勧めできません。ページがロードされるたびに JS が再ロードされ、キャッシュされた JS が適切に利用されなくなります。しかし、いくつかの外国の Web サイトのコードに注目すると、通常、js コードの後に乱数の代わりにバージョン番号パラメータが追加されることがわかります。このとき、バージョン番号に 1 を加えるだけで、クライアントに js ファイルの更新を通知する問題を賢く解決できます。この方法を最初に考えたのが誰なのかは知りませんが、彼が私たちの賞賛に値することは間違いありません。本当に良いアイデアです。

いくつかのコードが付属しています:

人気のチュートリアル

詳細>

jsファイルキャッシュのバージョン管理を詳しく解説_基礎知識