[React] React의 폴더 구조는 어떻게 정리하면 좋을까

학습없이 만들어낸 혼돈의 폴더 구조

리액트 프레임워크에서 작업을 하면서, 리액트는 어떠한 구조로 폴더를 관리하는지 궁금해졌습니다.
다른 프로젝트를 보면 폴더 구조가 동일하지 않은 경우도 있고, 스프링에서 쓰는 Controller, Service, Repository 같은 정형화된 패턴을 찾기도 어렵다는 느낌이었습니다.

정해진 표준은 없는지, 어떠한 형태로 폴더를 관리하면 좋을지 조사해보았습니다.

선 결론

      리엑트 프레임워크는 엄격한 룰에 의한 관리를 권장하지 않는다.
         즉, 정의된 표준 형태가 없다.
      그래서 라이브러리 마다 유연하게 관리한다. 권장 구조가 있을 때도 있다.
      따라서 프로젝트의 구조, 규모, 라이브러리에 따라 유연하게 작업한다.

참고 사이트

레거시 공식 문서

레거시 공식 문서에서는 2가지를 가이드하고 있습니다.

기능단위별 묶음

common/
  Avatar.js
  Avatar.css
  APIUtils.js
  APIUtils.test.js
feed/
  index.js
  Feed.js
  Feed.cs
  FeedStory.js
  FeedStory.test.js
  FeedAPI.js
profile/
  index.js
  Profile.js
  ProfileHeader.js
  ProfileHeader.css
  ProfileAPI.js

기능 단위별로 묶어, 파일 확장자를 구분하지 않고 묶어두는 형태.
단, '기능'의 정의는 특정한 개념이 아니므로 작성자에 따라 달라질 수 있습니다.

구조단위별 묶음

api/
  APIUtils.js
  APIUtils.test.js
  ProfileAPI.js
  UserAPI.js
components/
  Avatar.js
  Avatar.css
  Feed.js
  Feed.css
  FeedStory.js
  FeedStory.test.js
  Profile.js
  ProfileHeader.js
  ProfileHeader.css

API, 컴포넌트 등의 구조 단위로 묶어두는 형태.
원문에서는 Atomic Design 원칙에 기초한 형태로 역할에 따라 다른 폴더로 구분합니다.

두가지를 안내하면서도 이러한 형태에 큰 의미를 두지 말라고 합니다. 프로젝트가 커지면서 이를 혼합하여 사용할 수도 있으며, 처음에 올바른 방법을 선택하는 것이 중요하지 않기 때문입니다. 이러한 이유 때문인지, 최근 공식 문서에서는 해당 문서 자체를 찾을 수 없습니다.

Ant Design

중국에서 만든 디자인 프레임워크인 Ant Design가 있습니다. 해당 프레임워크는 'Page code structure recommendation'라는 이름으로 페이지에 기반한 형태를 권장하고 있습니다.

src
├── components
└── pages
    ├── Welcome // No other routing components should be included under routing components. Based on this convention, routing components and non-routing components can be clearly distinguished
    | ├── components // You can do more in-depth organization for complex pages, but it is recommended not to exceed three levels
    | ├── Form.tsx
    | ├── index.tsx // code of page component
    | └── index.less // page style
    ├── Order // No other routing components should be included under routing components. Based on this agreement, routing components and non-routing components can be clearly distinguished
    | ├── index.tsx
    | └── index.less
    ├── user // A series of pages recommend using a single lowercase letter as the group directory
    | ├── components // public component collection under group
    | ├── Login // page under group Login
    | ├── Register // page under group Register
    | └── util.ts // There can be some shared methods here, do not recommend and restrict, do your own organization depending on the business scenario
    └── * // Other page component codes

특히 라우팅 구성 요소를 중요하게 생각하고 구분하는 것을 권장하고 있습니다.
하지만 특정 프레임워크에서 설명하는 내용으로는 설득력이 부족했습니다.

How To Structure React Projects From Beginner To Advanced

How To Structure React Projects From Beginner To Advanced

이 글에서는 프로젝트의 규모에 따라 3가지를 이야기하고 있습니다.

가장 단순한 규모의 폴더 구조

src
  __tests__
  components
  hooks

가장 간단한 형태로, 10 ~ 15개의 컴포넌트만 관리할 경우에 적합합니다.
물론, 실제 도움이 되는 형태는 아닙니다. 이미지나 컨텍스트 등 필요한 항목이 더욱 필요하기 때문입니다.
정말 작은 프로젝트는 src에 모두 담아도 되기 때문에 큰 문제가 되지 않습니다. 그래서 중간 규모 폴더 구조를 소개합니다.

중간 규모 폴더 구조

src
  assets
  components
    __tests__
    form
    ui
  context
  data
  hooks
  pages
    Home
    Login
      __tests__
    Settings
    Signup
  utils

대부분 필요한 기능을 담아둔 형태입니다. 각 폴더에 대한 설명은 원문 블로그를 참고하시면 더 자세하게 설명하고 있습니다.
이 형태는 앞선 형태보다 2가지가 발전했습니다.

• 필요한 정보를 찾기가 편리하다 : page 내에서 관련 코드를 찾을 수 있으므로 유용하다
• 테스트 코드가 호출하는 영역에 세분화 되어있다 : 필요한 곳에서 테스트 코드를 관리하므로 추적이 편리하다

하지만 이도 단점이 있는데, 규모가 커질 수록 page에서 유용하게 찾아가던 효율성을 느낄 수 없게됩니다.
여러 곳에서 호출할 경우, 단일 페이지에서 관리하기 어렵습니다. 그래서 규모를 더 키운 형태가 등장합니다.
###확장된 규모의 폴더 구조

src
  assets
  components
  context
  data
  features
    authentication
      components
      hooks
      services
      index.js
    todos
  hooks
  layouts
  lib
  pages
    __tests__
    Home.js
    Login.js
  services
  utils

feature 폴더가 추가되었습니다. 페이지에서 관리하던 기능들이 feature에 공통으로 관리되면서 더 깔끔한 폴더를 구성할 수 있습니다.
기능을 한데 모아두고, index.js를 폴더 내부에 두어 노출이 필요한 기능만 index.js에서 호출할 수 있도록 제공하여 관리할 수 있습니다.

---

명확한 표준이 없어 정리하기는 어려우나, 공통된 부분을 얼마나 합쳐두고, 도메인과 관련된 부분을 얼마나 정리해두느냐에 중점을 둔다고 생각합니다.
결국 라이브러리 설정에 대한 부분은 각각의 폴더에서 관리하되, 그 안에서 도메인별로 확인할 수 있도록 분리하는 것이 좋은 형태라고 생각합니다.

지금 작업하는 1차 결과물이 완성되면, 중복 코드 제거와 소스 폴더 구조 정리를 적용하면서 더 나은 방법을 찾아보겠습니다.