私にとっては、現在最も成熟したソリューションのように見えます（間違っている場合は修正してください）。ブラウザのハッシュを操作するためのこのプラグインが本当に気に入っています。場合によっては、js コードが大幅に簡素化されます。
本格的に使い始めたいのですが、質問があります。
ソースに応じて、ループを使用し、50 ミリ秒ごとにハッシュ アンカーが変更されたかどうかを確認します。
パフォーマンスはどうですか？ハッシュチェンジを使いすぎてもいいですか? パフォーマンスが大幅に低下する可能性はありますか? もしそうなら、どのような場合に？
単純な文字列プロパティを 50 ミリ秒ごとにチェックすることは、実行している他のすべてのものと比較して非常に小さなコストです。ここではパフォーマンスについて心配する必要はありません。ハッシュを頻繁に変更していて、コールバックが非常に高価である場合は、それに対処します (コールバック) が、チェック自体は非常に小さなコストです。
window.onhashchangeまた、50 ミリ秒のチェックは、ネイティブ イベントである (そして最新のブラウザーである) ビルトインを持たないブラウザーのみを対象としていることにも注意してください。
パフォーマンスは問題ではありません。最新のブラウザはすべて onhashchange イベントをネイティブにサポートするようになったため、間隔チェックは必要ありません。
- より詳しい情報 -
jQuery History Pluginは、イベントをネイティブに実装していない古い世代のブラウザーに対して 200 ミリ秒のテストを使用します。onhashchangeそのイベントがネイティブに実装されていない場合、間隔の変更を使用してその機能を回避する必要があります。私の知る限り、他に方法はありません。幸いなことに、すべての主要なブラウザーの最新バージョンが onhashchange イベントをネイティブでサポートするようになったため、このチェックは不要になりました。
200 ミリ秒間隔のチェックが何をするか見てみましょう。IE6 または 7 を使用している場合は、iframe の状態をチェックします (これらのブラウザーでは、戻るボタンと進むボタンをエミュレートするために iframe が必要ですが、他のブラウザーでは iframe は必要ありません)。IE 以外の別の古いブラウザーを使用している場合location.getHash()は、チェックで使用できます (前に説明したように iframe は使用しません)。どちらのタイプのチェックも、必要なオーバーヘッドを最小限に抑えて、非常に高速かつ最小限に抑えるように設計されています。ブラウザが実際にユーザーに何をさせようとしているのか、可能な限り負荷の少ないコードを使用してそれを実行しようとしているかがすべてです。