Subscribed unsubscribe Subscribe Subscribe

@kyanny's blog

Write down what I learnt. Opinions are my own.

i18next.js と jQuery のロード順序が cache オプションに及ぼす影響について

i18next.js の初期化処理関数 i18n.init() は cache というオプションを受け取る(ドキュメントに記載は無い)

ソースコードを読むと、 options.cache が偽の場合、翻訳リソースファイル(たいてい translation.json という名前)を ajax リクエストで取得する際にクエリストリングにタイムスタンプを付与する。つまり以下の図のように http://localhost:8080/locales/en-US/translation.json?_=1423670283397 のような URL に GET リクエストをする。常に翻訳リソースファイルへのリクエスト URL が変化するので、ブラウザや CDN (Contents Delivery Network) のキャッシュを避けるのに役立つ。

f:id:a666666:20150212010039p:plain

ところがこの振る舞いは i18next.js より 先に jQuery がロードされていると変わってしまう。上記の cache オプションによるクエリストリング変更ロジックは i18next.js 自身に実装されている XHR (XMLHttpRequest) のラッパー関数の中にあるが、 i18next.js は $.ajax (jQuery.ajax) が利用可能ならばそちらを使い、自身の XHR ラッパー実装を使わないためだ。結果的に翻訳リソースファイルへは常に同じ http://localhost:8080/locales/en-US/translation.json のような URL で GET リクエストが行われる。

f:id:a666666:20150212010634p:plain

JavaScript や翻訳リソースファイルの配布に CDN を利用している複数の異なる環境があり、片方でキャッシュの問題が発生するのにもう片方では発生しないのが不思議でいろいろ調べた結果、上記のようなことがわかった。ライブラリの読み込み順(Grunt や Brunch などを使ってファイルを結合している場合は結合順)によって振る舞いが変化する、というのは作者でもなければ気づかない、見つけづらい罠だと思う。

検証につかったコードはこれ。

kyanny/i18next-cache-jquery · GitHub