Devpost 프로젝트 폴더 구조에 대한 고민

공식문서에서 권장하는 방식

1. 파일의 기능이나 라우트에 의한 분류

폴더를 기능 단위로 나누거나, 라우트 별로 나누어 분류하는 방식

라우트 같은 경우는 페이지를 기준으로 나눌 수 있겠지만

어떠한 기능을 기준으로 나눌것인가에 대한 것은 개발자의 선택에 달려있다.

세분화를 할수록 폴더의 깊이가 깊어질 것이고, 너무 단순하면 분류를 하는 의미가 없어질수 있다.

2. 파일 유형에 의한 분류

component, api, hooks, reducer 등 파일의 유형에 따라 폴더구조를 나눌 수 있다.

CRA와 같은 경우도 프로젝트를 생성하면 파일 유형에따라 폴더구조가 분리되어 있다.

3. 리액트 공식문서에서 권하는 조언

• 너무 많은 중첩을 피하세요
  • 중첩이 너무 많으면 파일을 import 하는것이 어려워진다.
  • 3 ~ 4번 정도까지만 폴더가 중첩되도록 하는것을 권장(어디까지나 권장사항이며, 엄격할 필요는 없음)

• 너무 깊게 생각하지 마세요
  • 프로젝트 처음부터 폴더구조를 5분 이상 고민하지 말고, 먼저 코드를 작성한 후에 고민해라
  • 정 모르겠으면 모든 파일을 하나의 폴더에 보관해놓고 시작해도 좋다. 그 다음 코드를 작성하면서 자주 묶어서 수정되는 것들을 같이 보관하는 방법도 있다.(colocation 방식)

4. 내 프로젝트에서 적용한 방식

1. components 폴더와 pages 폴더는 큰틀에서 페이지별로 폴더 구조를 분류함

   이유 : Next.js를 활용한 프로젝트 였기 때문에 pages 폴더는 라우팅을 위해 페이지 단위로 나누었어야 했음, pages 폴더와 components 폴더가 대응하도록 하는것이 가독성에 좋다고 판단해 components 폴더도 페이지 단위로 폴더 구조를 분류하였음.

2. 각 컴포넌트는 기능적인 부분(컴포넌트 부분)과 스타일적인 부분(styled components 부분)으로 파일을 분리하였고, 두개의 파일을 하나의 폴더로 묶어서 관리함

   이유 : styled components를 사용했기 때문에 한 파일에 스타일과 기능을 포함시키는 방법도 가능했지만, 기능적인 부분과 스타일적인 부분을 분리해서 관리하는것이 가독성이 더 좋다고 판단했음

프로젝트 링크