34

window.location.hashまたはを使用してURLを更新したいhistory.pushState。

それぞれの方法の違いと利点は何ですか？

4

9 に答える 9

33

location.hashhistory.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"}
于 2012-02-18T09:40:35.167 に答える
29

Pushstate は未来です。次の理由により優れています。

  1. よりきれいに見えます。
  2. ディープ リンクを再訪すると、SEO や Facebook Open Graph などをサポートする実際のサーバーサイド データを実際に表示できます (どちらもスパイダーを送信してページの html をスクレイピングします)。
  3. サーバーはハッシュタグデータにアクセスできないため、サーバーログには表示されないため、分析に役立ちます.
  4. ハッシュタグの問題を修正するのに役立ちます。たとえば、アプリにアクセスするユーザーを同じ https URL にリダイレクトするように Nginx を書き直しました。これはすべてのブラウザーで動作しますが、Safari はハッシュなしでドメインだけにリダイレクトします (面倒です)。
  5. 実際には、長いページのセクションへのディープリンクという目的のためにハッシュタグを使用できます。
  6. プッシュ状態をサポートしていないブラウザの実際の HTTP バックエンド リクエストを使用するようにフォールバックするか、ハッシュ タグを使用するようにフォールバックできます。どちらも追加の実装が必要ですが、少しの作業で簡単に実行できます。

詳細については、Github デザイナーによるこのトークを参照してください: http://warpspire.com/talks/responsive/

于 2012-05-18T06:38:46.507 に答える
15

これはかなり古い質問です (この返信の時点で 5 年以上) が、既存の返信に対する多くのコメントが、「現在の」状態に基づく更新を求めています。

契約は次のとおりです。

HTML5 の pushState は、すべての主要なブラウザーでサポートされています。古いブラウザーもサポートしている場合、history.jsは優れたポリフィルを提供します。これにより、pushState をネイティブに使用でき、古いブラウザーの従来の URL に簡単にフォールバックできます。しかし、pushState がネイティブにサポートされたからといって、それが確実に進むべき道であるとは限りません。

古い回答のいずれにも取り上げられていない非常に重要な点があります。それは、ハッシュ URL と pushState URL は表示方法が異なるだけでなく、実際には動作方法も異なるということです。この 2 つの基本的な違いにより、どちらかを選択することになる場合があります。

pushState はよりきれいでクリーンで、サイトやアプリのナビゲーションを完全に偽装するために使用できます。たとえば、GitHub はそれを使用して、すべてのナビゲーションを目に見えないように置き換えます。サイトのリンクをクリックすると、JavaScript を使用してそのクリックがインターセプトされ、新しいページをロードせずにページのコンテンツを更新する AJAX リクエストに変換されます。ロケーション バーの URL は、コンテンツに一致するように変更されます。取ってきた。これは、pushState が使用されることを意図していたものです。

GitHub の場合、http://mysite/page1とhttp://mysite/page2はどちらも有効な URL です。これらは「実際の」コンテンツへの「実際の」リンクであり、最初にどちらのページにアクセスしても、従来の MVC アプローチが使用されます。GitHub は、最新のブラウザーでのナビゲーションに pushState を使用しますが、必須ではありません。つまり、pushState は (彼らの意見では) ナビゲーションに関してユーザー エクスペリエンスを向上させるための「機能追加」として使用されます。ブラウザーのアドレス バーにリンクをコピーすると、javascript と pushState を介して形成されたリンクがコピーされますが、それでも実際の有効なリンクです。

ただし、スクラッチから始めて単一ページのアプリを作成し、MVC フレームワークを使用していない場合、特に動的バックエンドを使用していない場合 (つまり、コンテンツはすべて JavaScript を介して取得される場合)、実際には単一ページしかない可能性があります。 、サーバーによって生成されることはありません)。この場合、ハッシュ 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 の最大化を目的とした忌まわしいものですが、そうしなくても、サイトは問題なくナビゲートできます。

正解は、ニーズに最も適したものを使用することです。実際の URL があり、それらの間のナビゲーションを偽造したい場合は、pushState を使用して続行します (オプションで古いブラウザーのポリフィルを使用します)。ただし、単一ページのアプリを使用している場合は、そうしないふりをしないでください (よほどの理由がない限り)。ハッシュ URL を使用して作業を楽にし、不必要な問題を招かないようにしてから、pushState を使用してこれらのハッシュ URL を操作し、より優れたバック/フォワード サポートを利用します。

于 2017-06-30T15:30:46.697 に答える
14

history.pushStateよりも優れていlocation.hashます。しかし、それはHTML5の機能です。したがって、以下のようなフォールバック方法を使用することをお勧めします。

if (typeof(window.history.pushState) == 'function') {
    window.history.pushState(null, path, path);
} else {
    window.location.hash = '#!' + path;
}
于 2012-02-18T09:42:58.270 に答える
10

私は他の答えに同意しますが、ここに賛成する location.hashいくつかの議論があります：

  • Internet Exploder TMを含むすべてのブラウザで動作します
  • history.pushState は開発中の標準であり、API は将来変更される可能性があります
  • ユーザーが新しいウィンドウ/タブでリンクを開いた場合、ハッシュ URL により、ページをロードするために必要なサーバー リクエストがないことが確認されます (正しいキャッシュ ヘッダーが設定されている場合)。
  • サーバーが見るのはハッシュ部分のない URL だけなので、サーバーの構成は簡単です。

編集：1つ忘れました

  • ハッシュタグを使用すると、実際のリンク ( a href) を使用できます。そのため、クリック リスナーを設定する必要がないため、パフォーマンスが向上し、コード サイズが削減されます。
于 2012-07-08T11:54:45.337 に答える
7

window.location.hash と HTML5 history.pushstate の長所/短所は、主に、ページをどの程度劣化させたいかによって決まります。

ここでは、2 つの異なるシナリオでグレースフル デグラデーションに関心があるかもしれません。

最初のものは、javascript が有効になっていないクライアント、またはサイトにアクセスする自動化されたボット/クローラーです。これはSEOの観点から特に重要です。Web ページ/Web アプリケーションがハッシュ URL を使用している場合、これらのリンクを介して利用できるコンテンツは、これらのエンドユーザーには利用できません。これは、フォールバックなしでハッシュ URL を介してのみコンテンツのセクションを利用できるようにしている場合、決定的な問題です。ただし、ハッシュ タグ リンクを使用してアプリケーションの状態を変更し、ページが劣化した場合に単に意味を保持しない場合は、まったく問題ありません。

例として、タブ付きレイアウト ウィジェットの 3 つのタブで 3 つのセクションのテキストを使用できるページがあるシナリオを考えてみます。現在、2 つのシナリオが考えられます。最初のシナリオでは、ページの読み込み中にすべてのコンテンツを読み込みます。タブ付きウィジェットは、他のセクションを非表示にして特定のセクションを表示するだけです。したがって、タブ サムを作成するために使用するリンクでハッシュ URL を使用する場合、それらはクライアント側のアプリケーションの状態を変更するためだけに使用されます。JavaScript がオフになっている/利用できない場合、単にタブ付きレイアウトの構築に使用された JavaScript が実行されず、すべてのコンテンツがすぐに利用可能になります。この場合、さまざまなアプリケーションの状態は単に存在しないため、ハッシュ URL は、本来の目的である html のアンカーを指すだけに劣化します。この場合、html5 プッシュステートを使用する場合、ハッシュ URL の代わりに、それは悪い考えです。ユーザーが特定のタブへのリンクをブックマークする可能性がある理由。サーバーはそのURLを取得し、ユーザーが期待しているクライアント側の状態をユーザーに提示する必要があるためです。これは、クライアント側が独自の状態管理を行う必要があるシン サーバー アーキテクチャには適していません。もちろん、サーバー側でその側面を無視し、クライアントがページの読み込み時に最初に URL をチェックしてから、適切なアプリケーション状態に切り替えることができます。ただし、サーバー側のルーティング システムは、無視する必要がある追加の URL フラグメントのオーバーヘッドに関係しているため、美的な観点からそのフラグメントについてまったく気にするべきではないため、これは良い考えではありません。これは、ハッシュ URL が設計された要件に正確に対応しており、ハッシュ URL を使用することを強くお勧めします。代わりに 3 つのセクションで、特定のタブ サムがクリックされたときにテキストが動的に読み込まれる場合、ハッシュ URL を使用することはお勧めできません。その理由は、javascript が利用できない場合、ユーザーはリンクされたコンテンツにアクセスする方法がまったくないからです。これはSEOにとって特に悪いことです。このシナリオでは、サーバー側で URL (通常のシナリオでは「ハイジャック」および「ajax化」されます) を処理して、一般的にコンテンツを利用できるようにすると、エンドユーザー エクスペリエンスと SEO の両方の観点から優れています。その場合、ハッシュ URL を使用することはお勧めできません。その理由は、javascript が利用できない場合、ユーザーはリンクされたコンテンツにアクセスする方法がまったくないからです。これはSEOにとって特に悪いことです。このシナリオでは、サーバー側で URL (通常のシナリオでは「ハイジャック」および「ajax化」されます) を処理して、一般的にコンテンツを利用できるようにすると、エンドユーザー エクスペリエンスと SEO の両方の観点から優れています。その場合、ハッシュ URL を使用することはお勧めできません。その理由は、javascript が利用できない場合、ユーザーはリンクされたコンテンツにアクセスする方法がまったくないからです。これはSEOにとって特に悪いことです。このシナリオでは、サーバー側で URL (通常のシナリオでは「ハイジャック」および「ajax化」されます) を処理して、一般的にコンテンツを利用できるようにすると、エンドユーザー エクスペリエンスと SEO の両方の観点から優れています。

2 番目のシナリオは、html5 プッシュステートをサポートしていない時代遅れのブラウザーを使用しているクライアントです。上記の点は依然として保持されますが、さらに、no-javascript と同じレベルの劣化で pushstate のないユーザーを強制することは正当化できないと主張します。多くのエンド ユーザーは、なぜ劣化したバージョンを受け取っているのかまったくわかりません。

常に最新のテクノロジーを使用するという独断的な動機にタグを付けるのではなく、使用シナリオに最適なオプションを決定することをお勧めします。

于 2012-07-09T09:57:04.493 に答える
2

現在、pushState最新のすべてのブラウザでサポートされています。したがってpushStateよりも優れてlocation.hashいますが、これは HTML5 の機能です。

つまり、location.hash死んでいるわけではありません。実際には、非常に長い間存在します。

これを使用する良い方法は、 をサポートするライブラリpushStateを使用することですが、 location.hash.
例- https://github.com/browserstate/history.js

さらにlocation.hash、名前付きアンカーへのジャンプにも役立ちます。 pushStateWeb アプリの構築に非常に役立ちます。使うのが楽しみです。

于 2012-07-14T14:32:05.083 に答える
1

個人的には、PushState の方が URL の見栄えが良くなり、ユーザー エクスペリエンスにとって重要であると考えています。

pushStateを使用したいが、古いブラウザー サポートで問題が発生したくない場合は、 history.js ポリフィルを使用history.pushStateしてハッシュ フォールバックを使用できます。

于 2012-07-14T08:46:46.047 に答える