[디렉터리구조] src 하위 구조 관련

[eunohhh]

10월 16일 (수) 저녁 회의에 논의된 src 하위 구조 분류법에 관한 issue 입니다. gpt를 참고해 3가지 방안을 정리해 보았습니다.

1) src 하위에 바로 templates 디렉토리를 두고 페이지별 Template 컴포넌트 분류(도희님 의견과 비슷)

• 설명: 기능별 폴더 구조를 유지하면서 페이지 단위의 컴포넌트는 별도로 src/templates라는 디렉토리를 만들어 해당 컴포넌트를 유지합니다. 예를 들어, src/templates/auth/LoginTemplate.tsx처럼 페이지 템플릿 컴포넌트를 두는 방식입니다.
• 장점: 페이지와 관련된 파일들이 한 곳에 모여 있어 템플릿 관리가 수월하고, 페이지 컴포넌트의 역할이 분명히 드러납니다. 각 기능별 디렉토리는 비즈니스 로직 및 상태 관리에 집중할 수 있습니다.
• 단점: 컴포넌트들이 src 하위에 분리되어 있으므로, 기능별 코드와 컴포넌트 간의 연관성을 찾기가 다소 번거로울 수 있습니다.

2) 기능별 폴더 안에 templates 디렉토리 추가

• 설명: 기존 기능별 폴더 구조(src/auth) 하위에 templates 디렉토리를 추가하여 페이지 템플릿 컴포넌트를 해당 폴더 안에 넣습니다. 예를 들어, src/auth/templates/LoginTemplate.tsx처럼 배치됩니다.
• 장점: 기능별로 관련된 로직과 페이지 템플릿 컴포넌트를 한 폴더 안에 두어 연관성 있는 코드들을 모아 놓을 수 있습니다. 관리가 용이하고 각 기능 내에서 필요한 템플릿 파일을 명확하게 분류할 수 있습니다.
• 단점: 기능별 폴더에 템플릿 폴더가 추가되면서 파일 구조가 다소 복잡해질 수 있습니다.

3) 공통 components 디렉토리 안에 페이지 템플릿 관리

• 설명: src/components/pages 디렉토리를 두어 페이지 템플릿을 전역으로 관리하고, 기능별 로직은 그대로 유지합니다. 예를 들어, src/components/pages/LoginTemplate.tsx처럼 배치됩니다.
• 장점: 모든 페이지 템플릿 컴포넌트들이 한 곳에 모여 있어 일관된 구조를 유지할 수 있습니다. 특정 페이지에 필요한 공통 컴포넌트들도 함께 관리할 수 있습니다.
• 단점: 기능별로 분리된 파일 구조와 페이지 템플릿이 분리되므로, 특정 기능과 페이지가 어떤 관계를 맺고 있는지 파악하기 어려울 수 있습니다.

추가적인 의견 등등 코멘트 부탁드립니다 :)

[YISYISYISYIS]

1번이나 2번 괜찮을거 같네요 😀

[eunohhh]

회의 결과

월요일 회의후에 수정할 사항

• widget -> widgets 복수형으로 변경
• widgets/common -> widgets/components 로 변경
• invitations 폴더는 일단 살리되, widgets 폴더 밑으로 이동
• invitations에 있던 apis, constants, mutations, queries, types 는 widgets/ 바로 밑으로 이동
• invitations에 페이지별 구분처럼 있던 /catalog, /dashboard, /start 는 없애고
• 여기에 있던 컴포넌트들 widgets/components 로 모두 이동

사용하기로 결정된 구조 정리(이슈에 제시했던 3가지 안과는 다르게 결정됨)

• src/ 하위에 기능별로 구분 유지하기
• "종류Template.tsx" 나 그 외의 컴포넌트들 모두 따로 구분 없이 src/[해당기능]/components 에 보관

[iamheroine]

기능별 분류 시 내부 파일 구조 레퍼런스입니다!