最近よく愚痴を言いますが、ご存知のとおり、Web フロントエンドは数年前に比べて非常に重くなっており、さまざまな JS フレームワーク、さまざまなオブジェクトがあり、プロジェクトが多すぎるとパブリックになります。モジュールが抽出されます。
これらのモジュールの UI 表示は同じですが、違いはバックグラウンド ロジックです。たとえば、企業旅行を行う場合、通常、顧客が航空券を予約するときに入力するコスト センター用の js パブリック モジュールがあります。このコストセンターはオンライン、オフライン、アプリの予約端末に分散されており、将来的には顧客企業との月次決済も容易になります。
プロジェクトが大きくなり、より複雑になり、SOA になると、Web の理論と同じように、すべてのフロントエンド データが信頼できないため、他のチームのデータのインターフェイスが信頼できないこともわかっています。以前のプロジェクトが小規模だったときは、私もそれほど自信がなく、ロジック エラーが発生した場合にのみログを記録していました。結局のところ、情報ログは美しくありませんでした。また、サーバーの帯域幅を消費すると、Web パフォーマンスも低下します。
しかし、プロジェクトが大きくなり、ある日、プロジェクト内で奇妙なバグに遭遇したとき、あなたは不完全なログを頼りに、最終的にはインターフェースを一行ずつ肉眼で追跡します。しかし、パラメータが多すぎて、インターフェイスのパラメータ データを正確に復元できませんが、インターフェイスの戻りの問題であると確信していますが、現時点ではインターフェイス プロバイダーが見つかりません。 、あなたは無力でした 毎回考えた方が良いです 行ごとにログがあると良いでしょう。
この教訓を踏まえて、プロセス ログを保存する傾向がますます広まり、最終的には、Web バックエンドに関して混乱した形で多くのことが言われるようになりました。このような場合、現在のフロントエンドは同じである必要がありますか?これはパブリック JS モジュールであるため、このモジュールにはいくつかのメソッドがカプセル化されている必要があることがわかっています。次のようなサードパーティ プログラムが独自のテキスト ノードを操作することは絶対に許可されていません。
しかし、ここで問題が発生します。もちろん、さまざまな理由により、コストセンターで値を取得できない場合があります。これは、共通 UI のバグである可能性もあります。
ただ、その時点では本当に値が取得できたのかよくわかりませんでしたが、論理的には値が取得できなかったとしても原理的にはオーダーの投入を阻止することはできないので、バグを徹底的に追跡するために、ログを記録するために logCenter シングルトン クラスを作成しました。この方法は通常、js を使用してログを記録するために使用されます。
アヤックス
この方法は簡単に思いつきますが、ネイティブの xmlhttprequest を使用する場合はブラウザの互換性も考慮する必要があります。ただし、ネイティブの xmlhttprequest を使用しない場合は、サードパーティのフレームワークに依存する必要があります。 jquery と同じですが、結局のところ、まだ jquery を使用していない企業が多いため、実際のニーズに応じて使用する必要があります。
画像
dom には image というオブジェクトがあるので、その src に値を動的に割り当てることで、背景 URL をリクエストするという目的を達成できます。同時に、URL でタイトルとメッセージ情報を渡す必要があります。これにより、.src メソッドはブラウザの互換性の問題を考慮する必要がなく、非常に優れています。
上記がこの記事の主な内容ですが、今後さらに詳しく説明していきます