Q. 질문
멘토님 안녕하세요 ㅎ.ㅎ 첫 질문 떨리네요 🫢
저희 팀원들은 이전에 이런 구조를 많이 경험했어요
// 파일 구조 예시 ├── app │ └── components │ ├── main │ ├── searchBar.tsx │ └── button.tsx │ ├── mypage │ ├── notification │ ├── product │ └── common │ ├── _component │ ├── _util │ ├── _type │ └── main │ ├── page.tsx │ ├── mypage │ ├── page.tsx │ ├── notification │ ├── page.tsx │ └── product │ └── page.tsx └── public
- 이전 팀/개인 프로젝트를 진행할 때, 프로젝트의 규모가 커질수록 코드가 위치한 파일을 찾는 과정이 복잡해지는 불편한 경험을 했습니다.
- mypage 도메인 자체를 삭제하는 대공사가 발생한다면, 관련 코드를 삭제하기 위해 프로젝트 전체를 살펴봐야하는 불편한 경험을 했습니다.
이번 프로젝트에서는 이런 구조를 고민하고있어요
저희 프로젝트에서는 Next app라우팅을 사용하고있고, 아래는 이번 프로젝트에서 적용할 폴더구조입니다.
// 적용할 폴더구조 ├── app │ └── _common │ ├── components │ ├── hooks │ ├── constants │ ├── types │ └── utils │ ├── api │ └── main │ ├── page.tsx │ ├── _component │ ├── _util │ ├── _type │ └── _api │ └── mypage │ ├── page.tsx │ ├── _component │ ├── _util │ ├── _type │ └── _api └── public
- 위 구조와 같이 도메인에 따른 하위 폴더 구조를 형성한 이유는, 프로젝트의 확장을 고려해서 코드의 응집성을 높이기 위함인데요.
- 해당 폴더 구조를 가져감으로 앞에서 언급한 불편을 해결할 수 있지 않을까하는 기대감으로 적용해보려고 합니다.
- 팀원 전체가 해당 구조를 사용하는 것이 처음이고, 관련 레퍼런스를 못찾았습니다. 🥲 위 구조에서 저희가 고민하지못했거나 우려되는 문제가 보인다면 멘토님의 피드백으로 수정해보고 싶습니답
A. 멘토님 답변
좋은구조로 보입니다!
겪었던 문제를 도메인이나 페이지개념으로 디렉토리를 묶음으로써 해결할수있겠네요!
개인적으로 전 저의 의견을 듣고 방법을 바꾸기보다는, 함께 머리를 모아서 생각해내신 방법을 사용해보면서 좋은점과 불편함을 느껴보셨으면 좋겠어요!!
이게 눈으로보고 귀로듣는것보다 내가 더 가까이서 경험해봐야 살이되고 뼈가되더라구요.
중첩 라우터 구조를 어떻게 표현해낼지, app router에서 제공하는 방식이 있을지 정도만 알아보고 학습해보시면 좋을것같습니다!