MooTools jQueryが引き継いだ方法、またはコロンボスタイルの探偵

Airiでの作業中、ネットワーク/ブラウザインタラクションレベルで機能しているサイトのエラーを分析することがあります。 これは通常、要求/応答ヘッダーの単純な分析と、些細な条件の再現に帰着します。 しかし、時には興味深いケースがあります。



それはすべて寒い2月の夜に始まりました。 クライアントは、サイトを加速する際に奇妙な問題について書きました。スライドショーがサイトの動作を増やしてブロックし、ページにアクセスできませんでした。 すべての詳細を確認してから2日後、MootoolsとjQueryを一緒に使用することが許可されない理由を見つけました。 そして、「アルコールは悪」と「評価は悪」という考えで確認されました。



しかし、まず最初に。

トラブルの根本を見つける

現時点では、ブラウザには十分な数のプロファイリングツールがあり（この番号は多少冗長です）、問題のある場所を修正し、エラーを再現し、修正することができます。 これは、まず第一に：

• 開発者のツールのネットワークパネル：ブラウザーによって合法的に送信されたすべてのリクエストを、すべてのヘッダーと回答とともに表示します。 何らかの種類のトラフィック暗号化について話しておらず、リクエストに関する標準情報（ヘッダー、ステータス、サイズ）が必要な場合は、それで十分です。
• 開発者ツールのコンソール（バグ）。 問題が発生した場合、エラーの原因とコールバックスタックの両方を確認できます。 また、コードを実行するときにブラウザーの動作を繰り返します。
• DOMツリーとサイトソースコード。 どのプロパティが設定され、どのプロパティがHTML要素に動的に適用されたかは必ずしも明確ではありません。 ただし、ブラウザから直接直接情報を見ることができます。

単純なエラートレースについて話している場合、この記事は終了している可能性があります。 しかし、エラーは単純ではなく、再帰的でした。 また、ページが読み込まれた数秒後にブラウザタブが「倒れ」、エラーコンソールに次のトレースが残ります。



サイトでは、これは繰り返しのスライダーで表示されました（左右の複数の矢印は、エラーのためにスライダーのいくつかのコピーが互いに重なり合っています）：

叙情的な余談

MooToolsとjQueryの両方が圧縮された形でサイトに来たと言う価値があります。 ただし、jQueryにはソースマップが使用されたため、極端なもの（=有罪）の検索が非常に容易になりました。



ソースマップは、圧縮コードのデバッグに非常に役立ちます; 3番目の仕様は既にリリースされており、マップのサイズが数倍小さくなりました。 ソースマップについて初めて聞いた場合は、注意することをお勧めします。 しかし、先に進みます。

より深く掘る

どんな問題でも、問題につながる（ただし追加データなしで）最小条件を特定し、これらの条件を順番に分析することが重要です。 結局のところ、問題を安定して再現するための最小条件は、HTMLページにインラインJavaScriptコードが存在することでした。 ブラウザーおよびインターネットプロバイダーのキャッシュメカニズムにより、単純な結論を導き出せない場合があります。そのため、公開された暗号化されていないHTMLページを使用する場合、条件を数回明確に述べて再確認する必要があります。



しかし、HTMLにJavaScriptコードを含めると、ブラウザーで再帰的に実行されるようになったのはなぜですか？ YandexとGoogleはそのような状況について何も知りません。 私は彼を助ける必要があります。

仮説：少ない

一方で、すべてが明確です。JavaScriptインラインコードは再帰的に実行されるため、このサイトでは使用できません。 一方、インラインコードの再帰的な実行に正確につながるものは何ですか？



呼び出しスタックは、それを把握するのに役立ちます（上記のリスト）。 Bxslider（ Written while drinking Belgian ales and listening to jazz



-ベルギーのエールは間違いなく著者がいくつかの非標準的なシナリオを予測することを妨げた）





すべてが明らかなようです。jQueryは、ラッパーの残りの部分が終了するとすぐに、要素のネイティブメソッドを呼び出します。 この場合、それはimg["load"]()



です。 画像の読み込みイベントの完了につながるものは、ブラウザのキャッシュに依存する必要があり、誰もが満足する必要があります。 しかし、MooToolsライブラリはこの状況に同意しません。





MooToolsのload



メソッドは独自の方法で理解します。 そして、オブジェクトに関する情報がない場合、オブジェクトはnew Request.HTML



介してロードされます。 MooToolsに画像に関する情報がない場合は、画像をもう一度アップロードしましょう（結局、画像は既にブラウザキャッシュに読み込まれています。これは単にローカルユーザーのコンピューターのメモリ内の操作です）。 しかし、jQueryが画像に対してこのメ​​ソッドを呼び出すと、何らかの理由でパラメーター、特にURLを渡すのを忘れます。 おそらくjQueryは、MooToolsが引き続き動作することを知らないため、必要に応じてこれらのパラメーターが必要になります。 そして、パラメータのないMooToolsは「空の」URL（現在のページ）をロードします。



また、有効なレイアウトのように見えます：ページが読み込まれると、スライダーに5つの画像が読み込まれると（ブラウザーでこれが発生します）、ブラウザーはサーバーからさらに5回（HTMLドキュメントのみ）ダウンロードします。 ページがサーバーキャッシュにある場合、これは（ほとんど）パフォーマンスにまったく影響しません（また、開発者のネットワークツールバーのリソースで、写真とカウンターが混在するこれらの「余分な」呼び出しを見つけることも困難です）。



しかし問題は、デフォルトでは、MooToolsがロードされたHTMLドキュメント内eval



すべてのスクリプトのeval



実行することです。 そして、これはさらに悪いことです。サイトでカウンターのコードを数回実行しても生き残ることができます。 そして、DOMReadyハンドラーが開始され、スライダーが読み込まれ、画像が読み込まれ、HTMLページが読み込まれ、DOMReadyを実行するすべてのインラインコードが実行されると、アイデアが得られます。

まとめ

複数のJavaScriptフレームワークを共有しないでください。 決して（Joomlaの場合！システムからMooToolsをカットするプラグインさえあります）。 急にこの記事を読み直したい場合。 説明された問題は「表面上」であり、すぐに特定されました。 ただし、フレームワークの共同動作が、ネットワーク（遅延とリクエストの受け渡しの順序）および使用するブラウザに依存する場合があります。 そして、問題の原因を見つけて修正することはまったく考えられません。



eval



は、実行可能コードを制御する場合にのみ使用してください。 コントロールがない場合、評価はありません。



アルコールは悪、エールは悪です。 落ち着いたライフスタイルが私たちのすべてです。



ブラウザーの開発者ツールは、必要なすべての情報を実際に提供できます。 それらを使用できる必要があります。