<aside>

</aside>

개요

위의 대시보드 페이지에 대한 라우팅을 구현하려고 한다. 대시보드 페이지에서는 신청한 티클 관리와 개설한 티클 관리가 탭으로 전환되어야한다.

이를 구현하기 위해 3가지 방법이 떠올랐다.

1. /dashboard 페이지 내에서 탭을 state로 관리하기
2. /dashboard?tab=apply, /dashboard?tab=open 과 같이 탭을 query param으로 관리하기
3. /dashboard/apply, /dasyboard/open 두 개의 별도 페이지로 나누기

나는 이 중 3번째 방법을 채택했다.

그 이유는 신청한 티클 관리와 개설한 티클 관리가 UX 편의상 대시보드라는 하나에 페이지에 통합되어 있을뿐, 실제로 두 탭은 완전히 다른 데이터로 다른 기능을 하고 있는 별도의 페이지이기 때문이다. 두 탭 사이에서 공유되어야 할 상태도 없다.

따라서 1번이나 2번 선택지의 경우 두 페이지를 묶는 Wrapper 컴포넌트가 필요해지면서, 불필요하게 두 페이지 컴포넌트가 결합된다는 생각이 들었다.

구체적으로는, 1번 선택지의 경우 탭 전환이 브라우저 히스토리에 기록되지 않고 새로고침 시 탭 상태가 초기화되기 때문에 불편함을 줄 수 있다고 생각했다. 지금은 기능이 단순하지만 확장성을 생각했을 때, 만약 각 탭에서 다른 페이지로 이동하여 추가적인 작업을 하게 된다면 뒤로가기를 했을 때 탭이 초기화(변경)되는 것이 바람직하지 못하다고 생각했다.

2번 선택지의 경우, query parameter의 일반적인 쓰임이 검색이나 필터링 등에 쓰인다는 의미론적 측면을 고려했을 때 꼭 맞는 선택지는 아니라고 생각했다. 더불어 신청한 티클과 개설한 티클이라는 완전히 다른 독립적인 리소스를 다룬다는 측면에서 아예 다른 페이지로 분리하는게 좋겠다고 생각했다.

헤더 컴포넌트를 통해 페이지를 이동할 때 query paramter를 쓰지는 않는 것처럼 말이다. 즉, 대시보드 페이지 내의 탭은 그저 헤더 처럼 페이지 네비게이션을 위한 용도라고 볼 수 있다.

문제 상황

/dashboard/ 하위에 dashboard/apply와 dashboard/open이 존재하되, 중첩 구조로 구현하되 /dashboard에는 접속할 수 없어야 했다. 또한 apply와 open에 공통으로 필요한 ‘탭’을 상위에 렌더링하고, Outlet으로 각 페이지를 처리하고자했다.