서론 (겸 서비스 홍보)

얼마 전, 드디어 우리 서비스 출시를 했다. (신개념 북마크 서비스 '다담다' 바로가기)
출시를 하면 가장 하고 싶었던 유저 피드백을 열심히 모았고,

그 중 이번 스프린트에 반영할 피드백들을 1순위로 정해서 개발하고 있다.
오늘은 이 피드백 중 '로그인된 유저가 서비스에 접속하면 메인 페이지가 아닌 스크랩 페이지가 나타나기'를 다뤄보겠다.

요구 사항 정리

위 피드백의 요구사항을 명확히 해보면

서비스에 방문한 유저가
1. 이미 로그인된 상태일 경우 -> 스크랩 페이지를 보인다.
2. 로그인안 된 유저일 경우 -> 메인 페이지를 보인다.

이다. 처음 이 요구사항을 받았을 때는 도무지 어떻게 구현하는 건지 잘 모르겠어서 다른 이슈들 먼저 처리하면서 문득문득 고민해봤었다. 그리고 오늘 다른 유저 피드백을 처리하는 김에 꼭 해결하겠다는 마인드로 도전해보았다.

깃허브에서 답을 찾다...

위 경우 제일 큰 문제점은 도대체 무슨 키워드로 검색을 해야 답을 얻을 수 있을 지 확신할 수 없다는 것이었다. 그래서 저 기능이 구현된 다른 서비스, 깃허브 서비스로 넘어가 보았다.


이 둘을 열심히 관찰한 결과 하나의 깨달음을 얻었다.

해결책

// 기존 코드
<Routes>
	<Route path='/' element={<MainPage />}></Route>
<Routes>
  
// 새로운 코드
 <Route path='/' element={<RequireAuth><ScrapPage /></RequireAuth>}></Route>

그 전까지는 라우팅 경로가 '/'인 페이지에서 로그인된 유저가 들어오면 그 사람을 알아차려서 스크랩 페이지로 보내야 한다고 생각했다. 이러면 로그인된 유저가 '/' 경로로 가는 버튼을 눌러서 접속하는 경우와는 어떻게 구별해야할까에 대한 고민이 생긴다.

위 실험을 해보면서 반대로 생각하고 있었음을 깨달았다. 즉,

애초에 '/' 경로를 스크랩 페이지로 설정해놓으면 권한이 없는 유저는 protected routing에 의해 메인 페이지로 튕길 것이다!

(protected routing에 대한 경험담은 여기에 있습니다.)

사소한 문제

사실 위처럼 코드를 작성하면

이렇게 뜬다. 왜냐하면 ScrapPage는

function ScrapPage() {
  return (
    <ScrapTemplateContainer>
      <Navbar />
      <Outlet />
    </ScrapTemplateContainer>
  );
}

이렇게 생겨서 <Outlet/>을 통해 타입에 맞는 스크랩 페이지를 보여주기 때문이다. 기존 스크랩 페이지들처럼 Outlet 부분에 적절한 템플릿으로 채워주기 위해서 아래와 같이 코드를 추가했다.

 <Route path='/' element={<RequireAuth><ScrapPage /></RequireAuth>}>
 	<Route index element={<ScrapTemplate type={'list'} />}></Route>
 </Route>

원래는 path를 통해 slash 뒤에 list가 붙으면 list 템플릿을 불러오도록 설정하였는데, 이 경우 이를 사용할 수 없다고 판단하였다. 따라서, index설정을 사용하여 별도의 path 지정 없이도 list 템플릿을 불러올 수 있도록 설정할 수 있었다.

후기

사실 깃허브를 참고해서 구현하긴 했지만, 결과는 깃허브와 다르긴 하다. 깃허브는 로그인된 유저도, 로그인되지 않은 유저도 'github.com'이라는 url 주소가 유지되지만, 내 구현에서는 'dadamda.me'와 'dadamda.me/main'으로 다른 url 주소를 가진다.

추측으로는 깃허브의 실제 구현은 동일한 '/' 라우팅 내에 권한이 있는 유저라면 개인 페이지를, 권한이 없는 유저라면 메인 페이지를 렌더링하도록 처리를 하고 있지 않을까싶다. 그리고 아마도, 현재 프로젝트에서 진행중인 '보드' 기능의 공유 부분에서 우리 서비스도 사용하게 될 것 같다. 요즘 블로그가 좀 뜸했는데, 위 기능은 꼭 구현해서 추측처럼 구현이 가능한지 글로 작성하도록 하겠다!