프론트엔드 폴더구조 변화

1) Container / Presentational Components

배경

• 초기 React 시대에서 정석으로 여겨지던 폴더구조

• 하나의 컴포넌트에 UI와 로직이 모두 있게 되면
• 코드가 방대해지고
• 가독성 및 유지보수성 저하

• 이를 해결하기 위해 관심사 분리(Separation of Concerns) 원칙을 도입하여 UI와 로직을 분리
• View와 Logic 처리 책임을 철저히 분리

정의

• components/
• UI만 담당하는 Presentational Component
• props를 받아 시각적으로만 출력

• containers/
• 상태 관리, api 호출, 비지니스 로직 등 로직을 담당하는 Container Component
• 컨테이너가 컴포넌트를 품는 형태로 한 단위의 컴포넌트가 완성됨.

한계

• 규모 확장 시 탐색비용 증가
• 낮은 응집도
• 과도한 탐색 비용 발생
• components, containers가 각각 flat하게 커지면서 연관파일을 찾을 때 과도한 마우스 이동 및 탐색 시간 소요
• 이외에도 styles, hooks, tests 등 기능 단위로 폴더를 나누게 되면서 탐색비용 낭비는 더욱 커짐.
• 생산성 / 유지보수성 저하
• 협업 시 연관 파일을 함께 열기 어렵고 변경 포인트가 흩어짐

• 모호한 경계
• UI만 있는 것은 어디에 속해야 하나?
• 컨테이너 없이 컴포넌트만 있어도 되나?
• 로직만 새로 작성되고 UI는 다른 컴포넌트들을 재사용 하기만 한다면 컴포넌트는 필요없나?
• 컴포넌트 조합의 책임은 어디에 있나?
• 뷰가 엄청 작은 컴포넌트도 뷰를 분리해야 하나?
• 뷰의 추상화 정도는 어느정도가 되어야 하나?

2) Component-Centric 구조