SPA로 구성된 프로젝트를 SSR 프레임워크 중 하나인 Remix 공부를 진행하다가 Nested Route 방식을 통해 중첩된 구조의 페이지를 구현을 하려고 했습니다. 폴더를 만들고 Nested 한 구조를 만들고자 관련 폴더들을 생성하고 파일을 생성하여 개발을 진행하고 있는데, 원하는 방식대로 Nested 한 구조의 라우트로 연결되는 것이 아닌 404 페이지로 이동이 되는 문제를 확인하였습니다. 이때 시도하고 있는 방식이 Remix의 V1 라우팅 방식이라는 것을 공식 문서를 통해 확인을 하게 되었고, V2와 어떤 라우팅 방식의 차이를 가지고 있는지 비교하는 포스팅을 하려고 합니다.
Remix의 Future 플래그
Remix에서는 초기 V1을 만들때 V2를 2023년에 개발을 진행하고 릴리즈를 진행했던 적이 있습니다. 여기서 나오는 개념은 Remix의 Future 플래그입니다. Remix는 Next와 동일하게 React의 서버 프레임워크로 급부상을 하면서, Remix의 급격한 메이저 업그레이드가 지속적으로 이루어지고 있었습니다.
메이저 업그레이드로 인해 기존에 사용하던 기능들이 레거시가 되고, 그에 대한 새 기능이 생기거나 변화하는 케이스가 생겼습니다. 이렇게 된다면 이전 버전 Remix를 통해 개발된 웹 프로젝트에서 버전 업그레이드를 하기 위해서는 많은 작업 필요하게 되고, 성능 이슈나 보안적 결함으로 불가피하게 업그레이드 해야하는 경우 많은 공수가 들게 됩니다.
그래서, Remix는 아래와 같은 목표 아래 프로젝트를 계속해서 디벨롭을 하게 됩니다.
· Sematic Versioning 단위로 주요 기능이 업데이트 될 때 해당 기능들을 선택적으로 사용할 수 있어야합니다.
· 사전에 미리 주요 기능을 채택한 개발자는 빠르게 주요 버전으로 업그레이드를 할 수 있어야합니다.
이때 Remix 팀에서는 두 개의 플래그를 제시하고 있습니다.
future.unstable_feature과 future.v2_feature 플래그를 통해 remix.config.js 파일에 설정을 하면 됩니다.
future.unstable_feature
· 해당 플래그는 미래에 정식으로 나올 기능을 미리 사용할 수 있도록 설정할 수 있고, 불안정하거나 버그가 있다는 뜻은 아닙니다.
· Remix 팀에서는 해당 플래그를 적극적으로 사용하길 권합니다. 최종 릴리즈에서 출시된 API를 그때야 적용할 수 있는 것보다는 미리 적용을 해보는 것이 좋다고 생각한다고 합니다.
future.v2_feature
· 해당 플래그는 V1 버전의 기능에서 주요 변경 사항이 생긴 버전을 사용한다는 의미입니다. V2 API는 안정적이기에 주요 변경 사항이 적용되지 않고, V2 API가 곧 기본 사양이 된다는 의미입니다.
· 시간이 날때 V2로 업그레이드를 해놓으면 버전 업데이트가 원활합니다.
따라서 해당 플래그를 통해 만들어진 새 기능 개발 이후의 릴리즈 라이프 사이클 예시는 아래와 같습니다.
Non-Breaking + Stable API Feature ➠ Langs in V1
· 크지 않고 안정적인 기능일 경우 V1에 릴리즈
Non-Breaking + Unstable API ➠ future.unstable_ flag ➠ Lands in V1
· 크지 않고 안정적이지 않을 경우 future.unstable_ flag를 통해 사용할 수 있고, 추후 V1에 릴리즈
Breaking + Stable API Feature ➠ future.v2_ flag ➠ Lands in V2
· 크고 안정적인 기능일 경우 future.v2_ flag를 통해 사용할 수 있고, 추후 V2에 릴리즈
Breaking + Unstable API ➠ future.unstable_ flag ➠ future.v2_ flag ➠ Lands in V2
· 크고 안정적이지 않을 경우 future.unstable_ flag를 통해 사용하다가, future.v2_ flag를 통해 사용할 수 있고 추후 V2에 릴리즈
Remix v2
The second major release of Remix is stable today.
remix.run
이때 당시 V2의 경우, 시험적인 기능이 많았기 때문에 V1을 사용하는 개발자들에게 시험적으로 관련 기능들을 사용할 수 있도록 config 설정에 대한 내용을 공유하였고 현재 2024년에는 기본 기능을 V2를 채택하여 사용을 하고 있기 때문에 라우팅 방식도 V1과 다르게 V2에서는 확연하게 방식이 달라졌습니다.
RemixJS nested routes not found
I just started a new application using RemixJS on React (with typescript) but my nested pages aren't loading and I can't seem to figure out why. I'm pretty new to Remix so maybe I'm doing something...
stackoverflow.com
초기에는 V2를 사용하기 위해서는 config 설정을 통해 사용을 할 수 있었는데, 현재는 V1이 레거시가 되고 기본 설정으로 V2를 사용해줘야하기 때문에 리믹스 라우트 관련 내용을 한번 가볍게 읽어보았습니다. 앗, 물론 V1 라우트 설정을 사용할 수도 있습니다. 아마 오래 전 부터 리믹스를 사용하신 분들은 V1에 대한 문법들이 익숙할 수도 있기 때문에 아래의 간단한 설정을 통해 V1 기능을 사용할 수 있습니다.
(remix.config.js 설정을 진행합니다)
/** @type {import('@remix-run/dev').AppConfig} */
module.exports = {
ignoredRouteFiles: ["**/.*"],
// appDirectory: "app",
// assetsBuildDirectory: "public/build",
// serverBuildPath: "build/index.js",
// publicPath: "/build/",
future: {
v2_errorBoundary: false,
v2_meta: false,
v2_normalizeFormMethod: false,
v2_routeConvention: false,
},
};V1의 Nested Routed 방식
V1의 경우, 중첩 폴더 방식을 통해 Nested Routed 방식을 구현할 수 있습니다.
최상단에 접근할 라우트 파일과 Nested로 접근할 파일 및 폴더를 구성할 수 있습니다.
기본적으로 Remix의 라우터는 routes 폴더 안에서 관리를 하고 있기 때문에, 위의 사진과 같은 구조를 띄우고 있습니다.
다만 V1 기능을 사용하기 위한 config 설정을 제외하고는 현재 Remix에서는 V2를 디폴트로 사용하고 있기 때문에 해당 방식으로 접근이 되지 않고, 다른 방식으로 라우트 방식을 채택을 하고 있습니다. 그렇다면 변경된 라우트 방식으로는 어떻게 Nested Route를 접근할 수 있을까요?
V2의 Nested Routed 방식
위에서 살펴보았던 V1의 경우, 중첩된 경로를 위해 폴더 구조를 사용했습니다. 폴더로 경로를 표현하고, 그 폴더 안에 여러 라우트 파일을 두는 방식을 통해 구현을 했습니다. 중첩된 UI를 만들기 위해 폴더를 많이 사용해야했고, 이는 복잡한 라우팅 구조에서는 폴더가 너무 깊어지는 문제가 발생할 수 있었습니다. Remix 공식문서에 따르면, 권장하는 라우트 방식은 다음과 같습니다.
Route File Naming | Remix
remix.run
중첩 라우팅을 보다 간결하게 표현하기 위해 파일명에 .을 사용하여 중첩 구조를 표현할 수 있습니다.
이 방식은 폴더의 깊이를 고려할 필요없이, 하나의 파일 내에서 경로의 중첩을 표현할 수 있는 방식입니다.
app/
├── routes/
│ ├── _index.tsx
│ ├── about.tsx
│ ├── concerts._index.tsx
│ ├── concerts.$city.tsx
│ ├── concerts.trending.tsx
│ └── concerts.tsx
└── root.tsx
이 방식은 아래와 같은 특징을 같습니다.
간결한 폴더 구조
· .을 사용하여 파일 명에 경로를 직접 표현할 수 있기 때문에, 폴더 구조가 깊어지지 않아도 복잡한 라우팅 구조를 간단하게 관리할 수 있습니다.
중첩 라우팅 관리가 쉬워짐
· 중첩된 경로를 파일명으로 바로 확인할 수 있기 때문에, 폴더를 계속해서 중첩시키는 것보다 더 쉽게 구조를 파악할 수 있습니다.
폴더 깊이 감소
· 폴더 구조를 깊게 만들지 않고도 복잡한 중첩 라우트를 쉽게 정의할 수 있어, 폴더 깊이가 얕아지고 프로젝트의 가독성이 높아집니다.
마무리
사실 우리에게 익숙한 방식은 V1에서 제공하는 Nested Route 구조가 아닐까 싶습니다. 단순한 파일 구조 및 카테고리화를 통한 폴더 구조를 좋아하는 개발자라면 V1의 라우팅 방식을 선호할 것이고, 폴더의 깊이감있는 구조를 싫어하는 개발자라면 V2의 라우팅 방식을 선호할 것이라고 생각이 됩니다. 이번 포스팅에서는 V1의 익숙하던 라우팅 구조로 인해 적용이 안되었던 V2의 라우팅 구조를 확인할 수 있었습니다. 레거시함과 미래 지향적인 코드를 둘 다 챙겨보고자 하는 리믹스의 철학이 이번 포스팅을 위해 공부를 진행하면서 너무나도 이상적이고 흥미로웠습니다.
댓글