
사내에서 Next.js 스터디를 하게 되었습니다!
그 중 이번에는 2주차 주제인 Routing에 대해서 알아볼 예정입니다.
App router를 사용하고 있기에 이를 기반으로 뽀개보자!
목차는 아래와 같습니다.

Next.js Routing 공식 문서 (14버전)
Next.js 버전 13에서 새로 소개되었습니다.
이전 pages 에서 작동했던 방식처럼 app 폴더에서 동작하고, page 폴더와 함께 사용될 수 있습니다.
app 폴더 안에 있는 컴포넌트들은 기본적으로 React Server Components 입니다.
"use client" 를 통해서 client component 로 사용할 수 있습니다.

How Routing and Navigation Works
앱 라우터는 라우팅과 네비게이션에 하이브리드한 접근 방법을 사용합니다. 서버에서는 애플리케이션을 구성하는 코드가 라우터의 세그먼트에 따라 자동으로 분산이 됩니다. 클라이언트에서는 라우터의 세그먼트를 prefetch나 캐시로 사용니다. 이 말은 유저가 새로운 경로로 접근하면 브라우저는 새로운 페이지를 불러오지 않는다는 것이고 변경된 경로 세그먼트만 다시 렌더링하여 탐색 경험과 성능을 향상 시킨다는 것입니다.
application code를 작은 번들로 나누어 각 요청마다 전송되는 데이터의 양을 줄이고, 실행 시간을 줄여 성능을 개선합니다.
서버 컴포넌트는 route segments 로 application code가 자동적으로 split 되도록 합니다.
Next.js 는 Router Cache 라고 하는 in-memory client-side cache 가 있습니다. 사용자가 페이지를 돌아다니는 동안, prefetched route segment 의 리액트 서버 컴포넌트 페이로드와 방문한 route들이 캐시에 저장됩니다.
이 말은 탐색 시, 서버에 새로운 요청을 하는 대신 최대한 캐시를 재사용 한다는 것을 말하고 요청 수와 전송되는 데이터 수를 줄여 성능을 향상한다는 의미입니다.
부분 렌더링의 의미는 공유된 세그먼트는 다시 불러오지 않고 변경된 세그먼트만 다시 불러온다는 뜻입니다. 예를 들어 /dashboard/settings와 /dashboard/analytics가 있다면 /dashboard가 제공하는 레이아웃은 재사용하고 /setting과 /analytics의 부분은 새로 불러온다는 것입니다.
부분 렌더링이 없으면 모든 페이지가 재호출 될 때 서버에서 모든 부분을 새로 그릴 것입니다. 공유된 부분은 그대로 사용하고 변경된 부분만 새롭게 그리는 것이 서버의 자원을 아끼는 데 매우 도움이 됩니다.
기본적으로 브라우저는 페이지간 하드 네비게이션으로 동작합니다. 이 말은 브라우저는 모든 페이지를 다시 불러오고 React의 상태를 모두 리셋시킨다는 것을 말합니다. 그러나 Next.js App Router는 소프트 네비게이션을 제공합니다. 이 말은 리액트가 React와 브라우저 상태를 유지하면서 변경된 세그먼트만 렌더링하며 전체 페이지를 다시 로드하지 않는다는 것을 말합니다.
Back and Forward Navigation
뒤로가기나 앞으로 가기 시 기본적으로 스크롤 위치를 유지하고, Router Cache에 있는 route segments 를 재사용합니다.
app 디렉토리는 일반적으로 URL 경로에 따라서 폴더들이 계층을 가지고 있습니다. 하지만 개발자가 특정 폴더를 라우트 그룹이라고 표시를 하면 특정 폴더를 라우트 URL 패스에 포함되지 않도록 막을 수 있습니다.
이것을 사용하면 URL 경로 구조에 영향을 주지 않고 라우트 세그먼트와 프로젝트의 파일을 조직화 할 수 있게 해줍니다.
Routing Group (folderName)과 같이 써주면 자동으로 생성이 됩니다.

병렬 라우트(Parallel Routes) 는 동일한 레이아웃 안에서 동시에 혹은 조건부로 하나 이상의 페이지를 렌더링할 수 있습니다. 이 방법은 대시보드, 소셜 사이트 피드와 같이 동적인 앱에서 활용도가 매우 높습니다.

병렬 라우트는 이름이 있는 slot에서 생성된다. slots 은 @ 기호를 사용해서 만든다. 예를 들어, 아래의 파일 구조는 두 개의 슬롯, @analytics 와 @team 으로 구성된 구조다.

추후 WTS를 개발할 때 이런 병렬 라우트를 활용하면 좋겠다고 생각이 들었다. 이렇게 구분되어 있는 레이아웃에서, 작업 범위를 나누기에도 좋을 것 같고, 충돌도 피할 수 있을 것 같았다.

라우트 가로채기는 현재 레이아웃 안에서 라우트를 로드하면서 현재 페이지의 컨텍스트를 유지할 수 있게 해줍니다. 이러한 라우팅 패러다임은 특정 경로를 "가로채서" 다른 경로를 표시하고 싶을 때 유용합니다.
예를 들어, feed 내부에서 사진을 클릭할 때 feed 위에 모달이 나타나야 합니다. 이 경우, Next.js는 /feed 경로를 가로채고 이 URL을 /photo/123 대신에 보여줍니다.

그러나 공유 가능한 URL을 클릭하거나 페이지를 새로고침하는 경우와 같이 사진에 직접 이동할 때는 모달 대신 전체 사진 페이지가 렌더링되어야 합니다.
intercepction routes (..)와 같은 표기를 통해서 생성할 수 있습니다.
(..) : 한 디렉토리 위의 route를 인터셉트한다.
(...) : app디렉토리를 기준으로 상대경로를 인터셉트한다.

NextGram에서 parallel routes와 intercepting routes에 대해 테스트를 해볼 수 있습니다.
Intercepting Routes을 활용한 모달과 아닌 것을 비교해봅시다!
데모 사이트: https://nextgram.vercel.app
해당 데모 사이트에서 1번을 클릭하면 보이는 모달과 실제로 URL로 접근한 모달이 다르게 보이는 것을 확인할 수 있습니다.

이제 다른 모달을 볼까요?
토스증권 WTS 뉴스 모달 사이트

다른 모달을 보며,,, 우리가 개발할 때는 사용자 경험을 위해서 어떤 것들을 선택하게 될까..?
참고
https://nextjs.org/docs/14/app/building-your-application/routing
https://velog.io/@hyunjoong/Next.js-13-Parallel-Intercepting-Routes-jxn0qt37
https://x.com/ctnicholasdev/status/1644130902006714371