[TIL] 리액트 라우팅과 전역 상태 관리: Router & Context API

1. 학습 배경

오늘 투두리스트(TodoApp) 수업 중 'Provider'라는 생소한 단어가 등장했다. 찾아보니 useContext와 관련된 개념이었고, 이는 기존의 props 전달 방식의 불편함을 해결하기 위해 나온 것이었다.

또한, 라우팅 수업에서 교수님께서 Link가 아닌 Route 위주로 설명하시며 정적/동적 경로를 언급하셨는데, 이 부분도 개념이 모호하여 확실히 정리하고 넘어가려 한다.

---

2. React Router: 페이지 이동의 모든 것

처음엔 Link와 Route가 헷갈렸는데, 역할이 완전히 다르다.

2-1. Link vs Route (리모컨과 TV)

• Link (이동 버튼): 사용자가 클릭하는 메뉴. URL만 바꾼다. (HTML <a> 태그 역할)
• Route (화면 표시): 바뀐 URL을 감지하고 그에 맞는 컴포넌트(화면)를 보여준다.

2-2. path와 element

Route를 설정할 때 사용하는 핵심 속성이다.

• path: 브라우저 주소창에 찍힐 경로 (예: /login)
• element: 해당 경로일 때 보여줄 리액트 컴포넌트

2-3. 정적 경로 vs 동적 경로

• 정적 경로 (Static): 주소가 고정된 경우. (예: /about, /login)
• 동적 경로 (Dynamic): 주소의 일부분이 변수처럼 변하는 경우. 상세 페이지 등에서 사용된다.
  • 경로 뒤에 :id처럼 콜론을 붙여 사용한다.
  • 예: /product/:id (상품 번호에 따라 내용이 바뀜)

Spring 개발자 관점 비교:

• path & element = @GetMapping (매핑)
• useParams = @PathVariable (파라미터 추출)
• useNavigate = return "redirect:..." (강제 이동)

---

3. useContext: 데이터 전달의 혁신

3-1. 기존 방식의 문제점 (Props Drilling)

리액트에서 부모가 자식에게 데이터를 줄 때는 props를 사용한다. 하지만 데이터가 필요한 컴포넌트가 손자의 손자의 손자라면?

• 중간에 낀 모든 컴포넌트가 쓰지도 않는 props를 계속 전달만 해야 한다.
• 이것을 **Props Drilling(프롭스 드릴링)**이라고 하며, 코드가 지저분해지고 유지보수가 힘들어진다.

3-2. useContext와 Provider

이 문제를 해결하기 위해 등장한 것이 **Context API (useContext)**다.

• 개념: 데이터를 릴레이 경주처럼 넘겨주는 게 아니라, **방송국(Context)**에서 전파를 쏘면 라디오(컴포넌트)가 어디에 있든 바로 수신하는 방식이다.
• Provider (제공자):
  • 데이터(state)를 가지고 있는 데이터 전달자이자 공급소이다.
  • 트리의 최상위(혹은 공통 부모)에서 하위 컴포넌트들을 감싸주면, 그 내부에 있는 모든 컴포넌트는 데이터에 접근할 수 있게 된다.

3-3. 비교 정리

구분	useState + Props	useContext + Provider
데이터 전달	부모 → 자식 (직접 전달)	Provider → 필요한 하위 컴포넌트 (직통)
전달 단계	단계별로 모두 거쳐야 함 (Drilling)	중간 단계 건너뛰고 바로 사용 가능
사용처	가까운 부모-자식 간 데이터 통신	전역적인 데이터 (테마, 로그인 정보 등)

---

4. 오늘의 결론

1. 라우팅: Link는 문을 여는 손잡이, Route는 문 뒤에 있는 방이다. path로 주소를 정하고 element로 방을 꾸민다.
2. 데이터: Props는 옆 사람에게 물건 건네주기, useContext는 확성기로 모두에게 방송하기다. 이때 확성기 역할을 하는 것이 바로 **Provider**이다.

확실히 Spring의 개념과 매핑하고, 문제 해결(Props Drilling) 관점에서 바라보니 이해가 빨랐다. 프로젝트에 바로 적용해 봐야겠다.