簡単に回避できる3つのJS公開エラーを詳しく紹介_基礎知識

Web アプリケーション開発では、すべてのユーザー ロジックと対話コードがクライアント側で実行され、サーバーが REST または RPC インターフェイスを公開する傾向があります。コンパイラはプラットフォームとして JS をターゲットにしており、ECMAScript の第 2 版はこれを念頭に置いて設計されました。 Backbone、Ember、Require などのクライアント側フレームワークは、コードが豊富なだけでなく、個々のコンポーネント、コンポーネントとデータ間の多くの相互作用を備えた機能豊富なアプリケーションの作成を促進します。
これは非常に優れており、優れたユーザー エクスペリエンスを生み出す可能性がありますが、Web アプリケーションや Web ページの開発が難しいことは間違いありません。
根本的な原因は、コードとデータをインターネット上で提供し、ランダムなブラウザ上で実行される JavaScript (特に注意が必要な言語) は、コードのデプロイメントが完全に欠けているプラ​​ットフォームであることです。そしてそれはすぐには改善されません。もしスタートレックが現実だったら、ジャン＝リュック・ピカード船長が時々戦えなかったのは、彼がまだダッシュボードにクリリンを積んでいたからだと思う。
比較的よくある 3 つの間違いと簡単な解決策に焦点を当て、私たちが遭遇して ReadyForZero から学んだいくつかのユニークなことについて話したいと思います。
「キャッシュクリア」ヘッダー情報を削除します
CDN を使用して静的リソースをキャッシュすることもできますが、これは確かに合理的です。サーバーからキャッシュされていないリソースをリクエストしている場合は注意してください (AWS 側で「custom-origin」を使用してファイルを実際の Web サイトにポイントするなど)。これを実現するには、ファイルの新しいバージョンをデプロイした後、ファイル名にキャッシュクリア文字列 (ヘッダー情報) を追加し、ファイル名が次のようになります: http://www.jb51 .net/ js/main__V0123456789abcdef__.js
これは簡単に実行でき、任意のハッシュ アルゴリズムを選択して、ファイルの内容が変更されると変更されるようにフィンガープリント情報を生成できます。新しい URL が参照されるとキャッシュできないため、サーバー上の新しいバージョンを取得できます。ここでエラーが発生します。 Web 上には、「キャッシュクリア」ヘッダーを削除し、代わりにサーバーに新しいバージョンのファイルを直接提供するための推奨事項が数多くあります。 複数のサーバー クラスターがある場合、サイト上のさまざまなファイル (例: html、js) のバージョンが不一致になる可能性があります (例: js は更新されましたが、(別のサーバーから要求された) html は古いままです)。それだけではなく、さらに深刻です。それは、CDN が間違ったバージョンをキャッシュする原因となりやすいということです。このエラーは次のように発生します。
・最初はすべてのサーバーが HTML1 および JS1 です。
・サーバー A が再起動され、HTML2 および JS2 を提供します。
・クライアントは、CDN から main__V2__ を要求します。現時点では新しいため、CDN 上にキャッシュはありません。
・CDN はこのリクエストを設定したカスタムオリジンに渡し、たまたまこのリクエストがサーバー B に送信されました。
· サーバー B は「キャッシュクリア」文字列を削除し、古いバージョンを返します。
·CDN は古いファイルを新しいファイルとしてキャッシュします。
これは考えるのは簡単で簡単なことですが、インターネットのアドバイスに盲目的に従うと間違いが生じる可能性があります。さらに悪いことに、あなたにとってはすべてが正常に見え、エラーが発生したことさえ気づかないのですが、別の CDN を使用している他の地域のユーザーが間違ったバージョンをキャッシュしている可能性があります。解決策は、「キャッシュクリア」文字列を削除せず、各バージョンを正しくサポートする場所に静的リソースを配置することです。
2. 巨大な JS 爆弾への対処
JavaScript ファイルを圧縮して連結する必要があることは誰もが知っています。しかし、やみくもにそうするのは賢明な行動ではありません。連結されたファイルが大きい場合、より効率的な方法は、それらを並列化することです。さらに、ファイルの特定の部分を頻繁に変更する必要がある場合、多くの場所で障害が発生する可能性がありますが、ファイルの大部分は変更されていません。
頻繁に変更される部分を分離すると、双方の問題を解決できます。 require.js を使用することをお勧めします。これにより、JavaScript の真の依存関係管理が可能になり、最初のセットアップが簡単で (後で追加するのは面倒です)、非同期などの高度なオプションを含む依存関係の理解と管理に役立ちます。ロード中。
注: require.js は、リソースのロードを中止するまで一定時間待機します。これは、waitSeconds オプションを指定することで実現できます。これは、ユーザーがいる場所によって異なります。 (例: 携帯電話) )、これは非常に短期間である可能性があります。
3. エラー イベントの集約なし
JavaScript をオンラインにしたまま、その動作を気にしないというわけにはいきません。すべてのブラウザーとすべてのユーザーの状態の組み合わせをテストすることはできません。さらに、読み込み時間が異なると、奇妙な動作が発生する可能性があります。したがって、ユーザーがエラーに遭遇したかどうかを判断するために、何らかのフィードバック メカニズムを確立することが非常に重要になります。簡単です。エラーを収集してサーバーに送信するグローバル エラー ハンドラーを指定するだけです。以下は例です:
注意が必要なのは、ユーザーがさまざまな奇妙なプラグインなどをインストールしている可能性があるため、ゼロ以外のエラーが何度も発生することです。したがって、安定状態がどのような状態であるか、逸脱があるかどうかを追跡する必要があります。
ReadyForZero では、トップレベルで onError イベントをキャプチャしてサーバーに送信し、エラーを犯したユーザーの数とエラーが発生した場所を要約した日次レポートを生成します。多くの場合、エラー メッセージだけでは十分ではないため、イベント システムから最後のいくつかのイベントも返す必要があります。ユーザーによって最近トリガーされた Backbone イベントまたは JQuery イベントを分析すると、ユーザーがエラーをトリガーしたときのコンテキスト情報を取得するのに非常に役立ちます。
簡単に実現できる改善点
イライラするのは、これらのことは心配する必要がないということです。企業は製品にもっと重点を置き、製品を迅速かつ高品質で生産する必要があります。ただし、これらの簡単に実現できる改善が実装されれば、大きな動きにより集中できるようになるということを覚えておいてください。
人々は些細なことで行き詰まって多くの時間を費やしますが、アプリを立ち上げて実行するだけで大​​きな成長につながる可能性があります。
1. クライアント コードにメモリ リークはありますか?本気ですか？どうやって知りましたか？
2. ReadyForZero [注 1] には、このアートの推進に専念する多くの賢明な人材がいます。
[注 1] ReadyForZero: Y Combinator から資金提供を受けている会社です。同社の目的は、オンライン プラットフォームを通じて消費者がクレジット カードの負債を解消できるように支援することです。