history.pushStateとlocation.hashの違いは何ですか？
どちらかを使用してURLを更新しようとしています
window.location.hashまたはhistory.pushState。
それぞれの違い/利点は何ですか？
location.hash は history.pushState メソッドよりもサポートが優れています。pushStateメソッドの利点は、状態を履歴エントリにバインドできることです。
この状態オブジェクトが必要ない場合は、location.hashプロパティを使用して、古いブラウザとの互換性を高めることをお勧めします。
location.hash = 'new-hash';
console.log(history.state); // null or undefined
history.pushState({extraData: "some state info"}, '', 'new-hash'); //<---
console.log(history.state); // [object Object] = {"extraData": "some state info"}
Pushstateは未来です。それはより良いです：
- きれいに見えます。
- ディープリンクを再訪すると、実際のサーバーサイドデータを実際に表示して、SEOやFacebookオープングラフなどをサポートできます（両方ともスパイダーを送信してページのhtmlをスクレイピングします）。
- サーバーはハッシュタグデータにアクセスできないため、サーバーログに表示されないため、分析に役立ちます。
- ハッシュタグの問題を修正するのに役立ちます。たとえば、アプリにアクセスするユーザーを同じhttps URLにリダイレクトするようにNginxを書き換えました。 Safariを除くすべてのブラウザで機能します。Safariを使用すると、ハッシュなしでドメインのみにリダイレクトされます（とても煩わしい）
- 実際には、長いページのセクションへのディープリンクであるハッシュタグを使用できます。
- プッシュ状態をサポートしていないブラウザで実際のHTTPバックエンドリクエストを使用するようにフォールバックできますORハッシュタグを使用するようにフォールバックできます。どちらも追加の実装が必要ですが、簡単な作業で簡単に実行できます。
詳細については、Githubデザイナーによる次の講演を参照してください。 http://warpspire.com/talks/responsive/
history.pushState よりも良い location.hash。 HTML5の機能です。したがって、常に次のようなフォールバックメソッドを使用することをお勧めします。
if (typeof(window.history.pushState) == 'function') {
window.history.pushState(null, path, path);
} else {
window.location.hash = '#!' + path;
}
私は他の回答に同意しますが、ここにいくつかの引数があります賛成location.hash：
- internet Exploderを含むすべてのブラウザで動作しますTM
- history.pushStateは開発中の標準であり、APIは将来変更される可能性があります
- ユーザーが新しいウィンドウまたはタブでリンクを開いた場合、ハッシュURLは、ページをロードするために必要なサーバー要求がないことを確認します（正しいキャッシュヘッダーが設定されている場合）
- サーバー構成は簡単です。これは、サーバーが見るすべてのものがハッシュ部分のないURLであるためです。
編集：忘れました
- ハッシュタグを使用すると、実際のリンク（
a href）。したがって、クリックリスナーを設定する必要はありません。これにより、パフォーマンスが向上し、コードサイズが小さくなります。
Window.location.hashとHTML5のhistory.pushstateの長所/短所は、主にページをどの程度正確に劣化させたいかによって決まります。
ここでは、2つの異なるシナリオでの優雅な低下に関心があるかもしれません。
1つ目は、JavaScriptが有効になっていないクライアント、またはサイトにアクセスする自動ボット/クローラーです。これは、SEOの観点から特に重要です。 Webページ/ WebアプリケーションがハッシュURLを使用している場合、これらのリンクを介して利用できるコンテンツは、これらのエンドユーザーが利用できません。フォールバックのないハッシュURLを介してのみコンテンツのセクションを利用できるようにする場合、これは間違いなく問題になります。ただし、ハッシュタグリンクを使用してアプリケーションの状態を変更している場合は、ページが劣化しても意味が保持されないため、問題はありません。
例として、タブ付きレイアウトウィジェットの3つのタブで3つのセクションのテキストを使用できるページがあるシナリオを考えます。これで2つのシナリオが考えられます。最初のシナリオでは、ページの読み込み中にすべてのコンテンツを読み込みます。タブ付きウィジェットは、他のセクションを非表示にして特定のセクションを表示するだけです。したがって、タブサムの作成に使用するリンクでハッシュURLを使用する場合、それらはクライアント側のアプリケーションの状態を変更するためにのみ使用しています。 JavaScriptがオフになっている/利用できない場合、タブ付きレイアウトの作成に使用されたJavaScriptは実行されず、すべてのコンテンツがすぐに利用可能になります-適切な正常なフォールバック。この場合、さまざまなアプリケーションの状態は単に存在しないため、ハッシュURLは、意図された目的であるhtmlのアンカーを指すだけに低下します。この場合にhtml5 pushstateを使用するとしたら、ハッシュURLの代わりに、それは悪い考えでしょう。ユーザーがリンクを特定のタブにブックマークする可能性がある理由。サーバーはそのURLを取得し、ユーザーが期待しているクライアント側の状態をユーザーに提示する必要があるためです。これは、クライアント側が独自の状態管理を行う必要があるシンサーバーアーキテクチャには適していません。もちろん、サーバー側でそのアスペクトを無視し、ページのロード時にクライアントが最初にURLをチェックしてから、適切なアプリケーション状態に切り替えることができます。ただし、サーバー側のルーティングシステムは、無視する必要のある追加のURLフラグメントのオーバーヘッドに関係しているため、これは良い考えではありません。これは、ハッシュURLが設計された要件に正確に対応しており、それらを使用することを強くお勧めします。代わりに3つのセクションで、特定のタブのサムがクリックされたときにテキストが動的に読み込まれる場合、ハッシュURLを使用することはお勧めできません。 javascriptが使用できない場合、ユーザーがリンクされたコンテンツにアクセスする方法がないだけです。これはSEOにとって特に悪いことです。このシナリオでは、サーバー側でURL（通常のシナリオでは「ハイジャック」と「ajaxified」になる）を処理してコンテンツを一般的に利用できるようにすると、エンドユーザーエクスペリエンスとSEOの両方の観点から優れています。
2番目のシナリオは、html5プッシュステートをサポートしない時代遅れのブラウザーを使用しているクライアントです。上記の点が依然として当てはまる一方で、私はまた、no-javascriptと同じレベルの低下でpushstateのないユーザーを強制することは正当化できないと主張します。多くのエンドユーザーは、なぜ劣化したバージョンを受け取っているのか分からないでしょう。
常に最新のテクノロジーを使用するという独断的な動機と一緒にタグを付けず、使用シナリオに最適なオプションを決定することをお勧めします。
これはかなり古い質問です（この返信の時点で5年以上）が、既存の返信に対する多くのコメントが、「現在の」状態に基づいた更新を求めています。
ここに取引があります：
HTML5のpushStateは、すべての主要なブラウザでサポートされています。古いブラウザもサポートしている場合、 history.js は、pushStateをネイティブで使用し、古いブラウザのレガシーURLに簡単にフォールバックできる優れたポリフィルを提供します。 pushStateがネイティブでサポートされるようになったからといって、それが決定的な方法であることを意味するわけではありません。
これまでの回答では取り上げられなかった非常に重要な点があります。つまり、ハッシュURLとpushState URLは、表示方法が異なるだけでなく、実際には動作方法も異なります。この2つの基本的な違いにより、どちらかを選択するようになる場合があります。
pushStateはより美しく、すっきりしており、サイトやアプリ内のナビゲーションを完全に偽装するために使用できます。たとえば、GitHubはこれを使用して、すべてのナビゲーションを目に見えない形で置き換えます。サイトのリンクをクリックすると、JavaScriptを使用してそのクリックをインターセプトし、AJAXリクエストに変換します。このリクエストは、新しいページをロードせずにページのコンテンツを更新しますが、ロケーションバーは、フェッチされたコンテンツと一致するように変更されますこれは、pushStateが使用されることを意図していたものです。
GitHubの場合、 http：// mysite/page1 と http：// mysite/page2 はどちらも有効なURLです。これらは「実際の」コンテンツへの「実際の」リンクであり、最初にいずれかのページにアクセスすると、従来のMVCアプローチが実行されます。 GitHubは、最新のブラウザーでのナビゲーションにpushStateを使用しますが、必須ではありません。つまり、pushStateは（機能では）機能の追加として使用され、ナビゲーションに関してユーザーエクスペリエンスが向上します。ブラウザーのアドレスバーにリンクをコピーすると、JavaScriptとpushStateを介して形成されたリンクがコピーされますが、それでも実際に有効なリンクです。
ただし、スクラッチおよびシングルページアプリの作成から始めて、MVCフレームワークを使用していない場合、特に動的バックエンドを使用していない場合（つまり、コンテンツがすべてJavaScript経由で取得されている場合）は、実際には1ページしかない可能性があります。 、サーバーによって生成されることはありません）。この場合、ハッシュURLに対してpushStateを使用する場合、ブラウザーのURLが実際のURLではない場合に対処する必要があります。説明します。
ユーザーがシングルページアプリをロードします。 http：// mysite/mainpage
この時点で、ブラウザーバーにはアプリへの実際のリンクが含まれており、ユーザーには現在表示されているのと同じビュー、メインページが表示されます。次に、彼らはリンクをクリックして、いくつかの活動の詳細を示す「ページ」に移動します。この時点で、ロケーションバーを更新して、状態の変化を示します。ハッシュURLを使用し、ロケーションバーが http：// mysite/mainpage＃charts/1 のようになるか、pushStateを使用してだまして http：// mysite/mainpage/charts/1
PushStateを使用した場合、それは実際のリンクではありません。ブラウザーの戻る/進むボタンを介してナビゲートすることはうまく機能し、ユーザーはメインページからロケーションバーとアプリの両方で詳細ページに移動します（状態の変更を正しく処理したと想定）。ただし、ユーザーがこのリンクをブックマークした場合または、リンクをコピーして貼り付けて共有します。追加のサーバー側のブードゥーが必要になります。
リクエストを/ mainpage/charts/1から/ mainpageにリダイレクトし、JSを使用して実際のURLを解決し、意図した状態変更操作を実行する必要があります。サーバーのリダイレクトは絶対に必要です。スクリプト可能なhttpサーバーがないと、このページをAWSまたはローカルディスクでホストできません。
ハッシュURLを使用した場合、ユーザーが表示して操作するURLは http：// mysite/mainpage＃/ charts/1となり、有効な実際のURL。ブラウザーはページが1つしかないことを理解しており、ユーザーがリンクをコピーして貼り付けるかブックマークを付けるかに関係なく、JavaScriptでハッシュの状態を処理するだけで、サーバー側の魔法を使う必要はありません。
pushStateとハッシュリンクは相互に排他的ではないことは誰にも言及されていないようです。 pushStateは、ユーザーに表示されるブラウザーの場所を操作し、最新のブラウザーで信頼性の高いバック/フォワードナビゲーションを実装するための単なるAPIです。それはあなたのURLスキームがどのように見えるべきかについては何も述べていません。
2017年、Googleと他のほぼすべてのJS対応ボットはハッシュURLを理解し、それらをうまくトラバースしています。 Googleは＃を使用することを求めています！ SEOの最大化の目的でabominationしますが、そうしなくても、サイトは問題なくナビゲートできます。
正解は、ニーズに最も適したものを使用することです。実際のURLがあり、それらの間のナビゲーションを偽装したい場合は、pushStateを使用して続行します（オプションで古いブラウザーのポリフィルを使用）。ただし、1ページのアプリを使用している場合は、（非常に正当な理由がない限り）気にしないでください。不要な問題を引き起こさないようにハッシュURLを使用し、pushStateを使用してこれらのハッシュURLを操作し、より良いバック/フォワードサポートを利用してください。
現在、pushStateはすべての最新ブラウザーでサポートされています。したがって、pushStateはlocation.hashより優れていますが、これはHTML5の機能です。
ですから、location.hashは死んではいません。実際、それは長い間存在します。
これを使用する良い方法は、pushStateをサポートするlibを使用することですが、location.hashを使用することもできます。
例- https://github.com/browserstate/history.js
さらに、location.hashは、名前付きアンカーにジャンプする場合にも役立ちます。 pushStateは、Webアプリの構築に非常に役立ちます。どうぞよろしくお願いいたします。
私は個人的にpushStateを好みます。URLが見栄えがよくなるためです。これはユーザーエクスペリエンスにとって重要です。
history.pushStateは、pushStateを使用したいが、古いブラウザーサポートの問題は発生させたくない場合は、 history.js polyfill を使用したハッシュフォールバックで使用できます。