私はプログラミングに不慣れであるため、公式のドキュメントを読んだ場合、理解するのが少し難しくなります。

ここからReactRouter4について読んでいました

この記事では、著者が話していた<HashRouter>と<BrowserRouter>

これは彼が言ったことです

HashRouterは基本的に、URLのハッシュを使用してコンポーネントをレンダリングします。静的な1ページのWebサイトを構築していたので、これを使用する必要がありました。

BrowserRouterは、HTML5履歴APIを使用してコンポーネントをレンダリングします。履歴は、pushStateおよびreplaceStateを介して変更できます。詳細については、こちらをご覧ください

今、私は両方の重要性とユースケースを取得していません。彼が、pushStateとreplaceStateを介して履歴を変更でき、URLのハッシュを使用してコンポーネントをレンダリングすると言ったときの意味のように

BrowserRouterの最初の説明は私には完全に曖昧ですが、HashRouterの2番目の説明も意味がありません。たとえば、誰かがURLでハッシュ（＃）を使用してコンポーネントをレンダリングするのはなぜですか。

BrowserRouter

履歴APIを使用します。つまり、レガシーブラウザ（IE 9以下および同時代のブラウザ）では使用できません。クライアント側のReactアプリケーションは、example.com / react / routeのようなクリーンなルートを維持できますが、Webサーバーによってバックアップされる必要があります。通常、これは、Webサーバーをシングルページアプリケーション用に構成する必要があることを意味します。つまり、同じことindex.htmlが/ react / routeパスまたはサーバー側の他のルートにも提供されます。クライアント側でwindow.location.pathnameは、Reactルーターによって解析されます。Reactルーターは、/ react / route用にレンダリングするように構成されたコンポーネントをレンダリングします。

さらに、セットアップにはサーバー側のレンダリングindex.htmlが含まれる場合があり、現在のルートに固有のレンダリングされたコンポーネントまたはデータが含まれる場合があります。

HashRouter

URLハッシュを使用し、サポートされているブラウザやWebサーバーに制限はありません。サーバー側のルーティングは、クライアント側のルーティングから独立しています。

下位互換性のあるシングルページアプリケーションは、example.com /＃/ react / routeとして使用できます。サーバー側で提供される/パスであるため、サーバー側のレンダリングでセットアップをバックアップすることはできません。サーバー側から＃/ react / routeURLハッシュを読み取ることはできません。クライアント側でwindow.location.hashは、Reactルーターによって解析されます。Reactルーターは、と同様に、/ react / route用にレンダリングするように構成されたコンポーネントをレンダリングしますBrowserRouter。

最も重要なのは、HashRouterユースケースがSPAに限定されないことです。Webサイトには、レガシーまたは検索エンジンに適したサーバー側ルーティングがある場合がありますが、Reactアプリケーションは、example.com / server / side / route＃/ react / routeのようにURLでその状態を維持するウィジェットである場合があります。Reactアプリケーションを含む一部のページは、サーバー側で/ server / side / routeに提供され、クライアント側でReactルーターは、前のシナリオと同様に、/ react / route用にレンダリングするように構成されたコンポーネントをレンダリングします。

サーバー側： HashRouterはURLでハッシュ記号を使用します。これにより、後続のすべてのURLパスコンテンツがサーバー要求で無視されます（つまり、「www.mywebsite.com /＃/ person / john」を送信すると、サーバーは「www .mywebsite.com "。その結果、サーバーはpre＃URL応答を返し、post＃パスはクライアント側のreactアプリケーションによって解析されて処理されます。

クライアント側： BrowserRouterはURLに＃記号を追加しませんが、ページにリンクしようとしたり、ページをリロードしようとしたときに問題が発生します。明示的なルートがクライアントの反応アプリに存在するがサーバーには存在しない場合、リロードとリンク（サーバーに直接ヒットするもの）は404 notfoundエラーを返します。

BrowserRouterとHashRouterコンポーネントの両方が、RouterクラスのサブクラスとしてReact Routerver.4で導入されました。単純にBrowserRouter、UIをブラウザの現在のURLと同期します。これは、HTML-5 HistoryAPIを使用して行われます。一方、HashRouter同期にはURLのハッシュ部分を使用します。

「ユースケース」

HashRouter：バックエンドを必要としない小さなクライアント側アプリケーションがあるHashRouter場合、URL /ロケーションバーでハッシュを使用すると、ブラウザーはサーバー要求を行わないため、使用できます。

BrowserRouter：バックエンドを提供する本番環境に対応した大規模なアプリケーションがある場合は、を使用することをお勧めします<BrowserRouter>。

本による参照： Learning React：ReactとReduxを使用した機能的なWeb開発Alex Banks、Eve Porcello

ページを更新すると、ブラウザは現在のルートを使用してサーバーにGETリクエストを送信します。＃は、そのGETリクエストを送信できないようにするために使用されました。GETリクエストをサーバーに送信するため、BrowserRouterを使用します。サーバー上でルーターをレンダリングするには、場所が必要です。ルートが必要です。このルートは、サーバー上で何をレンダリングするかをルーターに指示するために使用されます。BrowserRouterは、ルートを同形にレンダリングする場合に使用されます。

追加したいもう1つのユースケース。BrowserRouterまたはRouterを使用している間は、ノードサーバーで正常に動作します。クライアントルーティングを理解しているため（事前構成済み）。

ただし、ビルドReactアプリをApacheサーバー（GoDaddyでPHPと言うだけ）にデプロイしている間、ルーティングは期待どおりに機能しません。404に到達します。そのため、.htaccessファイルを構成する必要があります。その後、私にとっても各クリック/ URL、サーバーへのリクエストの送信。

その場合は、HASHルーティング（＃）を使用する方が適切です。＃これをHTMLページで使用して、HTMLコンテンツをトラバースしますが、サーバー要求にはつながりません。

上記のシナリオでは、HashRoutingを使用できます。これは、＃の後に存在するすべてのURLであり、ルーティングルールをSPAとして機能させることができます。

基本的に、BrowserRouterを使用する場合は、「soAndSoReactPage /：id」のようなURLを使用できます。

例えば：

with a Route <Route path="soAndSoReactPage/:id"><soAndSoReactComponent/></Route>

これで、reactコンポーネント「soAndSoReactComponent」でuseParamsを使用して「id」を抽出できるため、idごとに「soAndSoReactComponent」ページを表示できます。

このようなことはHashedRouterでは実行できません。

https://github.com/ReactTraining/react-router/blob/master/packages/react-router-dom/docs/api/HashRouter.mdによると、作成者は一般的なシナリオでHashRouterを推奨していません。

この手法はレガシーブラウザのサポートのみを目的としているため、代わりにサーバーを構成して使用することをお勧めします。