react-router hash history and browser history
1643 ワード
最近SPAのおもちゃプロジェクトでreact-routerを使っていて、問題がずっと私を困らせています.私は公式のドキュメントに従って、browserHistoryを使って、それから生成したクライアントのルートはすべて#を持っていません.このように1つのサブレベルルーティングでページをリフレッシュすることは、このサブレベルルーティングを要求することであり、私のバックエンドはこのサブレベルルーティングを識別することができる.これは少し卵が痛くて、私が以前使った#/XXXのようなクライアントのルートとは少し違います.いいえ、作者はこの問題を考えていないはずがありません.きっと私がどこで使ったのか間違っています.そこで、私はまたドキュメントを見に行きました.この文書を見つけたHistoriesは、やっと私の疑問を解決した.
react-routerは、デフォルトのルーティングではなく、ルーティングを宣言する際に使用するルーティングを明示的に指定する3つの方法を提供します. browserHistory hashHistory createMemoryHistory
ブラウザに内蔵されたHistory APIを使用して実現されるbrowserHistoryが推奨されています.また、バックエンドは、ユーザが手動でページをリフレッシュするだけでなく、バックエンドに送信される可能性のあるルーティングを処理するための特別な構成も必要であり、さらに重要な理由がある.Historyプロパティがサポートされていない古いブラウザでは、react-routerがページを直接再ロードします(バックエンドでこれらのルーティングを認識する必要があるのは明らかです).
ドキュメントには、hash historyではなくbrowser historyを推奨する理由も記載されています.react routerは以前はhash historyをデフォルトで使用していたことを知っておく必要があります.
You might wonder why we don't fall back to hash history; the problem is that URLs become non-deterministic. If a visitor on hash history shares a URL with a visitor on browser history, and then they share that back, we end up with a terrible cartesian product of infinite potential URLs.
hash historyとbrowser historyの混用がurlを共有する際に混乱を引き起こすのを恐れているという意味だ.私は少しよく分かりませんが、1つのappは1つの方法しか採用できないはずです.混用しないでしょう.
まず穴を残して、後で調べてみます.stackoverflowで質問をして、なんとか疑惑を解決しました.ドキュメントの意味は、browser historyとhash historyを実行時に切り替えることであり、私が以前理解していたのではなく、実現する方法は1つだけです.それはurlを共有するとき、自然と混乱を引き起こす.
react-routerは、デフォルトのルーティングではなく、ルーティングを宣言する際に使用するルーティングを明示的に指定する3つの方法を提供します.
//v1.x
//v2.0.0
// hash history
import { hashHistory } from 'react-router'
ブラウザに内蔵されたHistory APIを使用して実現されるbrowserHistoryが推奨されています.また、バックエンドは、ユーザが手動でページをリフレッシュするだけでなく、バックエンドに送信される可能性のあるルーティングを処理するための特別な構成も必要であり、さらに重要な理由がある.Historyプロパティがサポートされていない古いブラウザでは、react-routerがページを直接再ロードします(バックエンドでこれらのルーティングを認識する必要があるのは明らかです).
ドキュメントには、hash historyではなくbrowser historyを推奨する理由も記載されています.react routerは以前はhash historyをデフォルトで使用していたことを知っておく必要があります.
You might wonder why we don't fall back to hash history; the problem is that URLs become non-deterministic. If a visitor on hash history shares a URL with a visitor on browser history, and then they share that back, we end up with a terrible cartesian product of infinite potential URLs.
hash historyとbrowser historyの混用がurlを共有する際に混乱を引き起こすのを恐れているという意味だ.私は少しよく分かりませんが、1つのappは1つの方法しか採用できないはずです.混用しないでしょう.
まず穴を残して、後で調べてみます.stackoverflowで質問をして、なんとか疑惑を解決しました.ドキュメントの意味は、browser historyとhash historyを実行時に切り替えることであり、私が以前理解していたのではなく、実現する方法は1つだけです.それはurlを共有するとき、自然と混乱を引き起こす.