Parallel, Intercepting Routes

Parallel, Intercepting Routes

Tech

들어가기 전..

Next.js 라우팅에 찾아보다가 Parallel, Intercepting Routes에 대해 알게 되었다. 신기해서 정리할 겸 글을 적어본다.

Parallel Routes

해당 라우팅 기법은 병렬 라우팅이라고 하는데 하나의 페이지에서 여러 슬롯을 렌더링할 수 있는 방법이다.

parallel routes

위 사진을 보면 @로 생성한 페이지 폴더를 layout.tsx에서 children으로 받을 수 있는데 이것들을 렌더링하면 하나의 웹페이지에서 여러 슬롯를 볼 수 있다. (hot reload가 적용안되서 껐다켜야 적용됨)

parallel routes 조건부 렌더링 위 사진처럼 Parallel Routes를 활용해서 특정 조건에 따라 슬롯(레이아웃을 동적으로 채우는 자리)을 조건부로 렌더링할 수 있다.

어떻게 동작할까?

soft navigation의 역할 덕분이다. soft navigation은 client side에서 페이지 리로드없이 url만 업데이트 되도록 하는 것인데, 이를 활용해서 Parallel Routes가 하나의 페이지에서 여러 슬롯이 동작할 수 있게 된다.(+ SPA로 동작하여 부분적으로 렌더링) 반대로 hard navigation이란 것도 있는데, 얘는 페이지 전체를 새로고침 함으로 슬롯 상태가 초기화된다는 특징을 가지고 있다. 페이지 새로고침하면 동작함.

유의점

@로 폴더를 만들어서 Parallel Routes를 적용할 때, 기본적으로 default.tsx를 만들어야 한다. 왜냐하면 해당 Routes가 적용된 페이지에서 슬롯들이 모두 비활성화인 상태면은 대신 렌더링할 기본 컴포넌트를 설정해야한다. 그것이 default.tsx이다. 만약 default.tsx를 만들지 않으면 404가 렌더링 되기 때문이다. 아래 코드를 보자.

/** app/@modal/default.tsx */
function Default() {
  return null;
}

export default Default;

null을 반환하는 이유는 모든 슬롯들이 비활성화 상태에서 아무것도 보여주지 않기 위해서이다. 그래서 null을 반환해 화면 상에 빈 공간이나 404가 안보이도록 설정한다.

언제 사용할까?

찾아보니 복잡한 페이지 레이아웃을 구성하고 서로 독립적인 UI를 렌더링할 때 사용하며, 성능을 최적화하고 빠른 UI를 전환하기 위해서이다. 내가 여기까지 읽고 나서 느낀점은 굳이 저렇게 페이지로 만들어서 처리해야하나? 라는 생각이 들었다. 페이지로 안하고도 컴포넌트 단계에서 처리해도 괜찮을 것 같은데,, 왜 쓸까?? 일단은 Intercepting 라우팅에 알아보자.

Intercepting Routes

해당 라우팅 기법은 기존 페이지를 유지하면서 다른 페이지의 경로를 가져와 로드할 수 있는 방법이다. 기존 페이지에 모달이나 추가적인 UI를 렌더링하는 데 사용된다.

intercepting routes 위 사진을 보면 feed 페이지에서 카트 컴포넌트를 클릭해서 해당 url로 이동한다. 하지만 페이지가 렌더링된 것이 아닌 모달로 렌더링 된 것을 확인할 수 있다. 만약 여기서 새로고침을 하면 어떻게 될까? 아래 사진처럼 그제서야 해당 페이지로 이동한다는 것을 알 수 있다.

intercepting routes2 이를 통해 사용자가 페이지를 사용함에 있어 사용자 흐름을 유지할 수 있게 되며 UX향상에 도움을 준다. 또한 상태를 관리하며 컨텍스트를 보존할 수 있다.

구현방법

페이지 폴더에 .을 사용하며 상대경로라 생각하면 된다.

intercepting routes 구현

  • (.) 같은 레벨에 위치할 때
  • (..) 1단계 상위 레벨에 위치할 때
  • (..)(..) 2단계 상위 레벨에 위치할 때
  • (…) 앱 폴더의 루트 경로에 위치할 때

응용

Intercepting 라우팅에 대해 알기 전까진, Parallel 라우팅의 필요성을 못느꼈다. 하지만 알고나니 이 둘을 같이 써야지 빛을 내는 것 같다. 바늘과 실같은 존재인데 Intercepting 라우팅을 안쓴다면 Parallel 라우팅은 굳이 쓸 이유가 없고 (페이지로 처리하는 것보단 컴포넌트로 처리하는게 훨씬 간단함. 개인적인 생각), Parallel 라우팅을 안쓴다면 Intercepting 라우팅은 제대로 동작할 수 없다. 그럼 이 둘을 함께 사용한다면 발생하는 시너지는 어떨까?

한번, 인스타를 예시로 아래 영상을 보자.

  1. 마이 페이지에서 feed카드 형식의 컴포넌트를 클릭을 했다.
  2. 모달이 렌더링 되면서 url이 바뀌었다. 하지만, 해당 페이지로 이동하지 않았다.
  3. 새로고침을 하니 그제서야 해당 페이지로 이동했다.

위 순서에 따르면 Parallel Routes가 Intercepting Routes를 동작할 수 있도록 구조적으로 받쳐주고 있다. 2번에 따르면 Intercepting Routes는 모달이 렌더링 되면서 기존 페이지의 url을 가리고 모달의 url로 바꾸었다. 이때, Parallel Routes 덕분에 페이지로 이동하지 않고 기존 페이지에서 계속 유지할 수 있도록 동작하는 것이다. => 얘의 역할이 기존 페이지에서 슬롯을 렌더링 하는 것이기 때문이다.(+soft navigation이 적용됨)

그리고 3번에 따르면 페이지를 새로고침 함으로써, hard navigation이 동작하여 슬롯 상태가 초기화가 되어 해당 url에 맞는 페이지로 이동한 것이다.

나도 구현해봤다.

마무리

폴더 기반의 라우팅 자체로도 Next.js를 사용하는 이유 중 큰 하나라고 생각하고 있었는데 이러한 라우팅 방식도 있다는 것이 정말 신기했다. 추후에 개발하다가 필요하면 적용해보도록 하겠다.

레퍼런스

#Next.js #Routing #Parallel #Intercepting