Parallel Routes 말 그대로 병렬적으로 라우팅이 가능하다는 이야기!
그래서 그게 뭔데 씹덕아; 라고 물어보신다면...
동일한 레이아웃 내에서 하나 이상의 페이지를 동시에 또는 조건부로 렌더링할 수 있는걸 말한다!
위 사진처럼 동일한 페이지에 서로다른 2개의 컴포넌트를 렌더링 할 수 있게 도와주는걸 Parallel Routes라고 한다.
그럼 여기서 그냥 1개의 컴포넌트에서 저 2개의 컴포넌트를 다 렌더링하면 되잖아 씹덕아 라고 말할 수 있겠다.
사실 대부분의 경우에는 위의 방법처럼 작성하는게 더 나을지도 모르겠다.
근데 Parallel Routes를 사용해서 구현하면, 위 사진에서 A컴포넌트와 B컴포넌트의 Loading State를 별개로 가지고 갈 수 있다는 장점이 있다.
동시에 2개 이상의 화면을 겹쳐서 렌더링하고싶고, 그게 동적으로 바뀌어야 한다면? 하나하나 내가 다 구현하는것 보다 더 효율적이지 않을까?
How to use?
그래서 어떤식으로 사용하면 될까?
바로 이전 포스팅으로 작성한 Intercepting Routes와 유사(?) 하게 간단한 컨벤션만 지켜주면 된다.
이렇게 폴더이름에 @를 포함해서 만들면 끝이다!
그러면 @가 포함된 path의 page.tsx는 Parallel Routes를 위한 components라는걸 알 수 있게된다.
여기서 당연하고도 중요한 이야기는, 해당 컴포넌트의 depth level이다.
이 사진과 같은 경우는 최상위인 app 바로아래에 parallel routes를 생성해 두었으니, 두개의 parallel routres component들은 props의 형태로 부모에서 사용가능한다.
즉, app/layout.js 에서 @team, @analytics 컴포넌트를 사용할 수 있고, children과 같이 병렬로 렌더링이 가능해진다.
@가 붙은 폴더이름의 경우 URL 구조에 영향을 주지 않는다! 마치 ()로 묶인 폴더처럼!
따라서@analytices/views라는 구조는/views와 동일하다.
즉,app/page.js는app/@children/page.js와 동일하다.
만약, 현재 route에서 참조할 수 없는 depth에서 parallel routes component를 만들어 두었다면!?
바로 404 에러를 만날 수 있다 :)
default.js
그럴때 우리를 도와줄 수 있는게 바로 default.js 혹은 default.tsx다.
일단 default라는 이름은, page, loading, error와 같이 reserved keyword이기에, 꼭 저 이름을 사용해야한다.
따라서 default.js를 사용해서 parallel routes component가 page를 로딩하는 과정에서 찾지 못할때 404에러를 반환할건데, 이때 404에러 대신 default.js에서 정의한대로 렌더링해줘!! 라는 의미가 되겠다.
마치 Suspense 혹은 Error Boundary의 Fallback이라고 생각하면 이해하기 더 쉽지 않을까 라는 생각이다!
참고
