[Init] 라우팅 세팅

[hummingbbird]

✏️ Summary

• close [Init] 라우팅 세팅 #12
  라우팅 기본 세팅 작업을 진행했습니다. 사용되는 페이지 전체 다 추가해서 연결해두었고, 모든 path 접근해서 테스트 해 본 결과 잘 연결됩니다~

📑 Tasks

주요 파일 역할은 다음과 같습니다.
paths.ts -> 경로 리스트
public-routes.tsx -> 로그인 없이도 접근할 수 있는 페이지 모음
protected-routes.tsx -> 인증된 사용자만 접근할 수 있는 페이지 모음
app-routes.tsx -> 모든 routes 모은 최종 router 파일(파일 목적이 더 직관적으로 드러나게 하기 위해 파일 명을 app-routes로 정했는데 router로 통일하는 게 좋다고 하면 그렇게 바꿀게요!)

경험 입력 페이지(experience-page.tsx)는 사용자 의도에 따라(수정/뷰어/생성) UI를 분기하는 구조로 설계했습니다. 각 모드의 UI는 매우 유사하지만 의도가 명확히 다르기 때문에 라우팅 단계에서 mode를 결정하고 내부 UI를 분기하는 방식으로 구현했습니다. 사용자 입력이 필요한 수정/생성은 ExperienceForm.tsx로, 보여지기만 하는 뷰어는 ExperienceViewer.tsx으로 분기되도록 하여 각 페이지의 목적에 맞게 적절한 화면이 보여지도록 해주었습니다😀

const ExperiencePage = ({ mode }: ExperiencePageProps) => {
  const { id } = useParams<{ id: string }>();
  switch (mode) {
    case "view":
      return <ExperienceViewer />;

    case "create":
    case "edit":
      return <ExperienceForm mode={mode} id={id} />;
  }
};

🔍 주요 논의 사항

🤔 폴더구조

경험 입력 페이지 폴더 구조에 대한 고민이 있습니다! 해당 페이지의 현재 폴더 구조는 아래와 같아요.

📦experience-detail
 ┗ 📂ui
 ┃ ┗ 📂experience-page
 ┃ ┃ ┣ 📜experience-detail-page.tsx
 ┃ ┃ ┣ 📜experience-form.tsx
 ┃ ┃ ┗ 📜experience-viewer.tsx

pages에서 slice를 나누는 기준을 '라우팅되는 페이지'로 잡았었죠! 앞서 말한 3가지 모드 모두 ExperienceDetailPage로 라우팅되기 때문에 해당 ui가 적절한 것도 같습니다. 그런데 또 다르게 생각하면 어찌 됐든 detail page 내부에서 분기처리가 되기 때문에 컴포넌트로 본다면 해당 위치보다는 features가 더 적합한가? 라는 생각이 들었습니다.

또한 '경험 매칭'도 경험처럼 하나의 도메인을 두고 리스트/상세 이런 방식으로 구분되는데 이런 것들을 pages/experience, pages/matching과 같이 도메인 기준으로 크게 한 번 더 감싸는 게 더 적절할지에 대한 고민도 있네요 .. fsd 어렵다!! 💦💦💦💦

근데 또?? 도메인이 같더라도 들어가는 컴포넌트가 도메인 별로 겹치는 건 아니라서, features 폴더 구조가 또 애매~해지더라고요? 정답이 없어서 더 어려운 폴더구조 !! 여러분은 어떻게 생각하시나요??

🤔 경험 입력 페이지

뷰어 모드까지 그냥 하나의 페이지로 합쳐서 isEdit 모드에 따라 textarea/text 이렇게 구분하는 방식도 있긴 있습니다! 그러나 그렇게 되면 하나의 페이지에서 컴포넌트의 분기 처리를 각각 해주어야 하고, 내용이 있고 없고에 따라도 달라지기 때문에 조건문, 삼항연산자가 매우 많아질 수 있다는 생각이 들었습니다🧐(+) 페이지의 기능을 고려하였을 때도 구분하는 게 더 적절한 거 같기도 하구요!)
어떤 방식이 더 적절한지, 더 선호하시는지 의견을 듣고 싶습니다!

👀 To Reviewer

1. 페이지 네이밍에 대한 피드백 2. 라우팅 경로 이름에 대한 피드백 3. 폴더 구조에 대한 피드백 부탁드립니다!😉😉

수정된 파일이 많은데 대부분 새로 추가된 페이지이니 주요 파일 4개만 보셔도 됩니다😙

마지막으로 추후 추가 작업이 필요한 부분은 TODO 주석으로 남겨두었고, 노션에 코드 추가해두었습니다~ 또한 랜딩 페이지는 아직 추가하지 않았습니다! 나중에 추가되면 그 때 추가하도록 하겠습니다~!

[github-actions]

🚀 빌드 결과

✅ 린트 검사 완료
✅ 빌드 성공

로그 확인하기

Actions 탭에서 자세히 보기

[u-zzn]

라우팅을 paths / public / protected / app-router로 역할 분리해 전체 흐름이 한눈에 들어와서 좋은 것 같습니다 :)
또 experience 페이지를 view / create / edit로 라우팅 단계에서 mode를 결정하고, 내부를 ExperienceViewer / ExperienceForm으로 역할을 분리한 구조도 저는 개인적으로 각각이 UI는 유사하지만 의도나 권한, 데이터 흐름이 다르기 때문에 상위에서 분기를 끊어서 구현한게 적절하다고 생각합니다 👍

위의 PR에서 적어주신 고민거리나, 질문들에 대한 저의 생각을 각각 정리해보면 아래와 같다고 할 수 있을 것 같습니다!!

---

1) 페이지 네이밍(라우터 파일)에 대한 의견

router보다는 app-routes.tsx로 쓰는 것이 (물론 Comfit 서비스에서는 생길 일이 없겠지만 예를 들어 보자면 admin-router와 같은) 여러 router가 생길 가능성을 대비하여 확장성이 더 좋다고 생각합니다 !! 다만 app-router.tsx처럼 관례적인 이름으로 통일해두면 더 좋지 않을까 생각합니다 ☺️

---

2) 폴더 구조(FSD) 고민에 대한 의견

이미 저희끼리 pages에서 slice를 나누는 기준 = 라우팅되는 페이지로 합의한 상태이니 ExperienceDetailPage가 라우팅 단위의 page이고 그 내부에서 모드 분기를 하는 현재 구조가 맞다고 저는 생각합니다!! 개인적으로 FSD에서 features는 기능이 재사용성이 있을 때 사용하는 것이 맞다고 생각하는데, 지금처럼 ExperienceForm/Viewer가 해당 페이지에서만 쓰이는 구성이므로 굳이 features로 내리면 오히려 탐색 비용이 올라갈 수 있다고 생각합니다ㅠ!!

다만 ui/experience-page처럼 중복 인상이 있는 구조는 아래처럼 단순화하면 좋을 것 같아요.

pages/experience-detail/
 ┣ experience-detail-page.tsx
 ┗ ui/
   ┣ ExperienceForm.tsx
   ┗ ExperienceViewer.tsx

그리고나서 예를 들어 ExperienceForm이 온보딩, 마이페이지 등 다른 플로우에서 재사용될 게 확실해지면 그 시점에만 아래처럼 분리하는 게 좋을 것 같습니다.

features/experience/create
features/experience/edit

pages는 조립과 라우팅만 담당하도록 역할을 좁히고요! 이건 제 개인적인 의견이니까 다같이 얘기해보아요!! 😽

(+ 도메인 기준으로 pages/experience, pages/matching처럼 한 번 더 감싸는 구조도 페이지 수가 많다면 고려해볼만하다고 생각하는데, Comfit 서비스에 맞게 저희끼리 한 번 더 회의해보면 좋을 것 같습니다 🖤)

---

3) 경험 입력 페이지를 “하나로 합칠지 / 분리할지”에 대한 의견

위에도 작성해놓았지만, 경험 입력 페이지는 지금처럼 라우팅 단계에서 mode를 결정하고, 하위 컴포넌트를 역할별로 분리하는 방식이 더 적절하다고 생각합니다.
view는 public 접근 가능성이 있고, create/edit는 인증·권한 체크가 붙기 쉬워 라우트 단 분리가 더 맞는 방식이라 생각하고, view는 조회 중심이고, create/edit는 폼 상태·검증·submit 흐름이 필요해서 한 컴포넌트로 합치면 조건 분기가 복잡해질 것 같다고 개인적으로 생각하는 바입니다 🥲

[u-zzn]

이 부분 오타 있는 것 같습니다!! MATCHING_LIST로 바꾸면 될 것 같아요 ☺️

[hummingbbird]

매칠링~ 감사합니다 ^-^!!!!

[odukong]

남겨주신 논의 사항들 중 주요 논의 사항으로 보이는 폴더 구조에 대한 개인적인 의견은 아래와 같아요.

detail page 내부에서 분기처리가 되기 때문에 컴포넌트로 본다면 해당 위치보다는 features가 더 적합한가?

ExperienceDetailPage 에서의 view, create/edit mode는 레이아웃은 거의 동일하지만, 사용자 관점에서 분명히 다른 목적을 가진 별개의 페이지들로써 동작을 하는 것이기 때문에 이들을 컴포넌트로 보기보다는 페이지로 다루는 관점이 적절하지 않을까 생각합니다.

그렇기 때문에 detail page의 view, form(create,edit)은 우선 pages에 위치하고 view, form(create,edit)내부에서 사용될 컴포넌트들은 하위 레이어인 features/experience-detail/ui path에서 정의하여 이를 pages 내부로 불러와 재사용하는 방식이 (1) features → pages로 참조되는 FSD의 단방향 의존성과 (2) 라우팅되는 페이지로 구분하는 pages layer의 역할에 부합하지 않을까 생각해요.

그리고 유진님이 예시로 작성해주신 폴더 구조에 저도 동의하는 입장이에요.

pages
 ┗ experience-detail/
	 ┣ experience-detail-page.tsx
	 ┗ ui/
	   ┣ experience-form.tsx
	   ┗ experience-viewer.tsx

experience-detail-page는 (하위 페이지를) 라우팅하는 역할을 중점적으로 수행하고 있기 때문에, experience-form과 experience-viewer와 같은 계층 상에 두기 보다 아래와 같이 experience-detail-page를 상위 계층으로 위치하고 하위 요소들이 experience-detail-page에 종속된 하위 ui임을 구조적으로 명시해주는 편이 좋다고 생각합니다.

그리고 말씀해주신 대로 viewer page까지 하나의 페이지(viewer,form,edit)로 합치는 방향으로 설계되면, 각 UI의 의도가 코드에서 잘 드러나지 않을 것 같아 mode에 따라 렌더링될 화면을 명확히 분리하는 구조가 가독성과 책임 분리 측면에서 더 적합할 것 같습니다!

라우팅 경로 또한 각 페이지의 역할이 직관적으로 드러나 있어서 적절하다고 생각해요.

/experience-matching 경로는 처음에는 기업과 정보를 매칭기능을 수행하는 페이지의 의미에 모호하지 않을까? 생각했는데, 사용자 입장에서는 기업 선택부터 결과 도출을 위한 단계적 입력까지 하나의 기능 플로우를 포괄할 수 있는 네이밍 충분히 자연스러운 것 같아요. (process 이렇게 단계적 의미를 담은 URL네이밍은 개발적 관점에 더 가까운 네이밍일 것 같더라구요💦)

PR에 남겨주신 고민들에서 단순한 라우팅 기능 구현뿐만 아니라, 구조와 추후 유지보수까지 고민하신 흔적이 보여서 인상 깊었습니다. 덕분에 저도 FSD 구조에 대해 다시 한번 생각해 볼 수 있었던 것 같아요. 수고 많으셨어요 o((>ω< ))o

[odukong]

기업 분석 세부 페이지에 대한 라우팅은 company-detail로 처리되고 있는 것 같은데,
혹시 같은 의미로 구성하신 폴더라면 제거해줘도 좋을 것 같아요 ❣️

[hummingbbird]

크아악 초기 세팅할 당시에 만들었던 파일인데 제거하는 걸 깜빡했네요 감사합니다 !

[hummingbbird]

로컬에서 해당 폴더가 추적이 안 돼서 보이지 않네요 .. 🥲 추후에 다른 작업 진행하면서 제거 해도 괜찮을까요?

[odukong]

아이구 물론입니다~ ^0^

[hummingbbird]

유진님, 수빈님이 제안해주신 구조가 더 적절하다고 판단되어 경험 디테일 폴더 구조 수정 완료했습니다~!

[qowjdals23]

흐 까다로운 라우팅 세팅 너무 수고하셨습니다!!
routes 로 경로를 한 군데로 모아두고(public/protected도 분리해두신 거), 덕분에 어디서 뭐가 정의되는지 동선이 확실해서 이후에 화면 늘어나도 관리하기 편할 것 같아요!
그리고 수빈님, 유진님 리뷰들도 빠르게 반영된 거 확인했는데, 불필요한 부분 정리된 것도 그렇고 전체적으로 더 매끈해진 느낌이네요 ❤️‍🔥

혹시 한가지.. 궁금해서 여쭤봐도 될까요오 🥹
ExperienceDetailPage에서는 useParams<{ id: string }>()로 제네릭을 붙여두셨던데, CompanyDetailPage / MatchingDetailPage / ExperienceViewer 쪽은 useParams() 그대로 쓰고 있더라구요 !
제가 잘 몰라서ㅜㅜㅜㅜ !! 이게 의도적으로 ExperienceDetailPage에서만 타입을 더 명확하게 잡아두신건지 궁금해서 질문드립니다 !

[hummingbbird]

혹시 한가지.. 궁금해서 여쭤봐도 될까요오 🥹 ExperienceDetailPage에서는 useParams<{ id: string }>()로 제네릭을 붙여두셨던데, CompanyDetailPage / MatchingDetailPage / ExperienceViewer 쪽은 useParams() 그대로 쓰고 있더라구요 ! 제가 잘 몰라서ㅜㅜㅜㅜ !! 이게 의도적으로 ExperienceDetailPage에서만 타입을 더 명확하게 잡아두신건지 궁금해서 질문드립니다 !

ㅎㅎ당연히 되죠! 아니요 의도적으로 한 것은 아닙니다! 처음에 만들 때는 타입을 넣어주었는데 그 후에 반복 작업을 하면서 제가 익숙한 방식(타입 지정하지 않는 방식)으로 하게 된 거 같아요 타입이 명확한 것이 아무래도 더 좋을 거 같으니 그렇게 수정하겠습니다 ㅎㅎ 감사해요 정민님 ~!!