React Router v4에 대한 히치하이커 가이드 : [경기, 위치, 기록] — 가장 친한 친구!

야! React Router v4, Part II에 대한 히치하이커 가이드에 오신 것을 환영합니다!

이제 첫 번째 작은 앱을 사용하여 공을 굴 리도록 설정 했으므로 경기 , 위치기록 의 세 가지 여행 동료에 집중하겠습니다 .

홈 컴포넌트 코드에 들어가서 거기에 console.log를 넣어 소품을 확인하면 어떻게 될까요?

라우터는 다음 개체를 구성 요소에 도입합니다.

와! 어디에서 왔습니까? ?

글쎄, 모든 뷰, 구성 요소 또는 라우터에 의해 래핑되는 모든 항목에는 이러한 개체가 있습니다. Higher Order Component로서의 역할을 수행하고 컴포넌트 또는 뷰를 래핑하고이 세 개체를 내부에 소품으로 삽입합니다.

그래서 ... 왜 거기에 있고 내가 그들을 어떻게 사용할 수 있습니까? ?

그들은 당신의 가장 친한 친구가 될 것입니다! 날 믿어! ?

시합

일치 객체는 방법에 대한 정보가 포함되어 있습니다 URL과 일치했습니다.

  • params : (객체), 경로의 동적 세그먼트에 해당하는 URL에서 파싱 된 키 / 값 쌍
  • isExact : (부울), 전체 URL이 일치하면 true (후행 문자 없음)
  • path : (문자열), 일치하는 데 사용되는 경로 패턴. 중첩 된 경로를 만드는 데 유용합니다 . 이 내용은 다음 기사 중 하나에서 나중에 살펴 보겠습니다.
  • url : (문자열), URL에서 일치하는 부분. 중첩 된 링크를 만드는 데 유용합니다.

따라서 Home 구성 요소에는 다음 같은 일치 개체가 있습니다.

isExact 는 전체 URL이 일치했기 때문에 true이고, 매개 변수 객체는 아무것도 전달하지 않았기 때문에 비어 있으며, 경로url 키 값은 isExact 가 true 임을 확인하는 동일 합니다.

이제 TopicList View를 살펴 보겠습니다 .

지금까지 새로운 것은 없습니다. Home View 에서와 동일한 이야기로 TopicList경로URL보여줍니다 .

하지만 TopicDetails살펴보면 어떨까요 ?

좋아요, 여기 뭐가 있죠?

전체 URL이 일치했기 때문에 isExact 는 계속 true입니다. params 개체는 구성 요소에 전달 된 topicId 정보를 가져옵니다 .

topicId 가 어떻게 변수 인지 주목하세요 .

그러나 Topic1 값 은 어디에서 가정 합니까?

간단합니다 . TopicList Links 에서 명시 적으로 호출합니다 .

URL을 알기 위해 TopicList 에 대한 일치 를 어떻게 사용했는지 확인하십시오 .

이 링크는 동적 일 수 있습니다 . 나중에 Topic1 또는 Topic3520 인지 이전에 알 수없는 상대 경로에 링크 하는 예제 를 수행 할 것 입니다.

그러나…

어떤 상황에서 isExact가 거짓입니까?

음… 예를 들어 보겠습니다.

이 상황 에서 브라우저 URL에 / HelloWorldSection 을 도입했습니다 .

라우터가 HelloWorldSection에 대한 전체 경로를 모르기 때문에 경로를 알 때까지 라우팅합니다.

isExact 는 " 전체 URL이 일치하지 않음 "을 정확하게 알려주는 false를 표시합니다 .

이것은 RRv4로 SPA를 시작하자마자 보게 될 것이므로 매우 유용합니다!

일치하는 접근 방식을 마치려면 다음을 확인하십시오.

화면에 주제 이름을 인쇄 하기 위해 match.params.topicId 를 사용했습니다 .

이것은 match 의 가장 일반적인 사용법 중 하나입니다 .

물론 다양한 응용 프로그램이 있습니다. 이 topicId 정보로 API를 가져와야한다고 가정 합니다. ?

위치

위치 당신이 가고 싶은, 심지어는 어디 어디 앱이 지금 어디 개체가 나타냅니다.

history.location 에서도 찾을 수 있지만 변경 가능하므로 사용해서는 안됩니다.

위치 는 탐색이 발생하는시기를 결정하기 위해 라이프 사이클 후크에서 사용할 수 있도록 개체가 돌연변이되지 않습니다. 이것은 데이터 가져 오기 또는 DOM 부작용에 매우 유용합니다 .

Home View 내 에서 console.log (location)을 보겠습니다 .

심층 분석을 많이하지 말고 단순한 기능을 유지하십시오.

당신은이 경로의 키 / 값입니다.

예를 들어 경로 이름 이 변경 되었는지 확인하는 데 사용할 수 있습니다 .

당신은 할 수 있습니다 또는 그것에. 나중에 보 겠지만 history.push 또는 history.replace를 수행 할 수 있습니다.

사용자 정의 개체를 만들어 사용할 수 있습니다.

  • history.push (locationX)

당신은 또한 그것을 전달할 수 있습니다 구성 요소.

이렇게하면 라우터 상태에서 실제 위치를 사용할 수 없습니다. 실제 위치와 다른 위치에서 렌더링하도록 구성 요소를 속이고 싶습니까?

이제 충분한 위치…

역사 로 이동합시다 !

역사

역사의 객체는 관리하고보기 또는 구성 요소 내부의 브라우저 기록을 처리 할 수 있습니다.

  • 길이 : (숫자), 히스토리 스택의 항목 수
  • action : (문자열), 현재 작업 (PUSH, REPLACE 또는 POP)
  • 위치 : (객체), 현재 위치
  • push (path, [state]) : (function), 새 항목을 히스토리 스택에 푸시합니다.
  • replace (path, [state]) : (함수), 내역 스택의 현재 항목을 바꿉니다.
  • go (n) : (함수), 히스토리 스택에서 포인터를 n 개 항목만큼 이동
  • goBack () : (함수), go (-1)과 동일
  • goForward () : (함수,) go (1)과 동일
  • block (prompt) : (function), 탐색 방지

이제 홈 뷰 에서 히스토리 개체를 console.log 하고 표시되는 내용을 살펴 보겠습니다 .

좋아, 정확히 우리가 기대했던 것.

PUSH 작업 을 통해 여기에 도착했음을 알려줍니다 . 개체 의 길이40입니다 (앱 히스토리 를 탐색 할 때 50 까지 증가하고 거기에서 멈춰서 이전 항목을 삭제하고 앱이 푸시 할 때마다 크기를 유지함). 개체에 대한 또 다른 기록 항목).

그것은 우리에게 위치 정보를 제공 합니다.

다시 말하지만, history 객체는 변경 가능 합니다. 따라서 history.location이 아니라 Route렌더링 소품 에서 위치 에 액세스하는 것이 좋습니다 .

이를 통해 React에 대한 가정이 라이프 사이클 후크에서 올바른지 확인합니다.

예를 들면 :

일반적으로이를 사용하여 브라우저 URL 경로를 변경할 수 있습니다.

아래 예에서 우리는 히스토리 푸시를 수행하는 버튼을 만듭니다.

물론 일부 데이터 가져 오기 또는 부작용 후 URL 변경을 트리거하는 데 사용할 수 있습니다.

컴포넌트를 호출하고 싶지 않은 JSX 중간에서 사용하는 것이 편합니다. 기록 푸시반환 하고 라우터 를 트리거 하여 브라우저 URL 을 업데이트 할 수 있습니다 .

마지막으로 중요한 것은

지금 쯤이면 이미 일치 , 위치기록 을 사용하는 방법에 대한 좋은 아이디어가 있다고 생각합니다 .

초기 상용구를 변경하지 않았으므로이 가이드의 1 부에서 제공하는 동일한 저장소에서 자유롭게 플레이 할 수 있습니다.

05. 참고 문헌

이 기사를 작성하기 위해 여기에서 찾을 수있는 React Router 문서를 사용했습니다.

내가 사용한 다른 모든 사이트는 문서를 따라 링크되어 정보를 추가하거나 설명하려는 내용에 대한 컨텍스트를 제공합니다.

이 글은“Hitchhiker 's Guide to React Router v4”시리즈의 2 부입니다.

  • 1 부 : Grok React Router 20 분
  • 파트 III : 무한과 그 너머로의 재귀 경로!
  • 파트 IV : 경로 구성 배열을 정의하는 숨겨진 값인 경로 구성

? 대단히 감사합니다!