나는 공식 문서를 읽으면 이해하기가 약간 어려워지는 프로그래밍에 익숙하지 않습니다.

여기에서 React Router 4 에 대해 읽었 습니다.

이 글에서 저자가에 대해 얘기했다 <HashRouter>및<BrowserRouter>

이것이 그가 언급 한 것입니다

HashRouter는 기본적으로 URL의 해시를 사용하여 구성 요소를 렌더링합니다. 정적 한 페이지 웹 사이트를 구축하고 있었기 때문에 이것을 사용해야했습니다.

BrowserRouter , HTML5 기록 API를 사용하여 구성 요소를 렌더링합니다. 기록은 pushState 및 replaceState를 통해 수정할 수 있습니다. 자세한 정보는 여기에서 찾을 수 있습니다.

그가 말할 때 지금, 나는 모두의 의미와 사용 사례를 얻을하지 않습니다처럼 그가 무엇을 의미합니까 역사는 pushState 및 replaceState를 통해 수정 될 수 및 그 구성 요소를 렌더링하는 URL의 해시를 사용하여

BrowserRouter에 대한 첫 번째 설명은 나에게 완전히 모호하지만 HashRouter에 대한 두 번째 설명도 의미가 없습니다. 왜 누군가가 url에 Hash (#)를 사용하여 구성 요소를 렌더링할까요?

BrowserRouter

히스토리 API를 사용 합니다 . 즉, 기존 브라우저 (IE 9 이하 및 동시대)에서는 사용할 수 없습니다. 클라이언트 측 React 애플리케이션은 example.com/react/route 와 같은 깨끗한 경로를 유지할 수 있지만 웹 서버의 지원이 필요합니다. 일반적으로 이는 웹 서버가 단일 페이지 애플리케이션 용으로 구성되어야 함을 의미합니다. 즉, / react / route 경로 또는 서버 측의 다른 경로에 index.html대해 동일하게 제공됩니다 . 클라이언트 측에서는 React 라우터에 의해 구문 분석됩니다. React 라우터는 / react / route에 대해 렌더링하도록 구성된 구성 요소를 렌더링 합니다 .window.location.pathname

또한 설정에는 서버 측 렌더링 index.html이 포함될 수 있으며 렌더링 된 구성 요소 또는 현재 경로에 특정한 데이터가 포함될 수 있습니다.

HashRouter

URL 해시를 사용하며 지원되는 브라우저 또는 웹 서버에 제한이 없습니다. 서버 측 라우팅은 클라이언트 측 라우팅과 독립적입니다.

이전 버전과 호환되는 단일 페이지 애플리케이션은 example.com/#/react/route 로 사용할 수 있습니다 . 셋업은이 때문에 서버 측 렌더링으로 백업 할 수 없습니다 / 서버 측에서 제공되는 경로 # / / 경로 반응 URL 해시는 서버 측에서 읽을 수 없습니다. 클라이언트 측에서는 window.location.hashReact 라우터에 의해 구문 분석됩니다. React 라우터는 .NET 과 유사하게 / react / route에 대해 렌더링하도록 구성된 구성 요소를 렌더링 합니다BrowserRouter .

가장 중요한 것은 HashRouter사용 사례가 SPA에 국한되지 않는다는 것입니다. 웹 사이트에는 레거시 또는 검색 엔진 친화적 인 서버 측 라우팅이있을 수 있지만 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 # 경로는 클라이언트 측 반응 응용 프로그램에서 구문 분석하여 처리합니다.

클라이언트 측 : BrowserRouter는 URL에 # 기호를 추가하지 않지만 페이지에 연결하거나 페이지를 다시로드하려고하면 문제가 발생합니다. 클라이언트 반응 앱에 명시 적 경로가 있지만 서버에는없는 경우 다시로드 및 연결 (서버에 직접 연결되는 모든 항목)은 404 찾을 수 없음 오류를 반환합니다.

"사용 사례"

HashRouter : 백엔드가 필요없는 작은 클라이언트 측 애플리케이션이 HashRouter있는 경우 URL / 위치 표시 줄 브라우저에서 해시를 사용할 때 서버 요청을하지 않기 때문에 사용할 수 있습니다 .

BrowserRouter : 백엔드를 제공하는 대규모 프로덕션 준비 애플리케이션이있는 경우 <BrowserRouter>.

책 참조 : Learning React : React 및 Redux를 사용한 기능적 웹 개발 Alex Banks, Eve Porcello

BrowserRouter와 HashRouter컴포넌트는 모두 React Router ver.4에서 클래스의 하위 Router클래스 로 도입되었습니다 . 간단히 BrowserRouterUI를 브라우저의 현재 URL과 동기화합니다. 이는 HTML-5 History API를 통해 수행됩니다. 반면 HashRouter에은 URL의 해시 부분을 사용하여 동기화합니다.

페이지를 새로 고치면 브라우저가 현재 경로를 사용하여 서버에 GET 요청을 보냅니다. #은 GET 요청을 보내지 못하도록하는 데 사용되었습니다. GET 요청이 서버로 전송되기를 원하기 때문에 BrowserRouter를 사용합니다. 서버에서 라우터를 렌더링하려면 위치가 필요합니다. 경로가 필요합니다. 이 경로는 서버에서 라우터에게 렌더링 할 항목을 알리는 데 사용됩니다. BrowserRouter는 경로를 동형으로 렌더링하려는 경우에 사용됩니다.

추가하고 싶은 사용 사례가 하나 더 있습니다. BrowserRouter 또는 Router를 사용하는 동안 노드 서버에서 잘 작동합니다. 클라이언트 라우팅을 이해하기 때문입니다 (사전 구성됨).

그러나 Apache 서버 (예 : GoDaddy에서 PHP)에 빌드 React 앱을 배포하는 동안 라우팅이 예상대로 작동하지 않습니다. .htaccess 파일 을 구성해야하기 때문에 404에 도착 합니다. 그 후 각 클릭 / URL, 서버에 요청을 보냅니다.

이 경우 HASH 라우팅 (#)을 사용하는 것이 더 좋습니다. # HTML 페이지에서 이것을 사용하여 HTML 콘텐츠를 탐색하며 서버 요청으로 이어지지 않습니다.

위의 시나리오에서 우리는 HashRouting을 사용할 수 있습니다. 즉, # 뒤에있는 모든 url은 SPA로 작동하도록 라우팅 규칙을 넣을 수 있습니다.

기본적으로 BrowserRouter를 사용하는 경우 "soAndSoReactPage / : id"와 같은 URL을 사용할 수 있습니다.

예 :

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

이제 반응 컴포넌트 "soAndSoReactComponent"에서 useParams를 사용하여 "id"를 추출 할 수 있으므로 id에 따라 "soAndSoReactComponent"페이지를 표시 할 수 있습니다.

HashedRouter로는 이런 일을 할 수 없습니다.