React Atomic vs Feature (Smart Component Pattern)

hooeee·2024년 2월 18일
AtomicDesignReact아키텍처

React

목록 보기
1/1
post-thumbnail

개요

  • 새로운 중대형 규모 프로젝트에서 사용할 React 아키텍쳐를 고민중입니다.!

React 공식 아키텍처

  • React는 느슨한 아키텍처를 지향하는 Library입니다.
    • 공식 아키텍처는 없습니다. 사용자의 자유도에 위임..!
    • Library이기에 아키텍처가 없는 것도 이유입니다.
    • 기존 공식 Document에도 느슨한 아키텍처를 지향하다고 명시 되었으나 최근에 글이 수정 된 모습…! (공홈주소→ https://ko.legacy.reactjs.org/docs/faq-structure.html)

🤔 Feature pattern이란?

  • 고전적인 디자인 패턴으로 초창기에 Smart Component Patten와 같은 의미 입니다.
  • 기능 단위로 Component를 분리한 패턴입니다.
    • 공통 컴포넌트는 따로 분리합니다.
    • 기능 단위로 페이지를 분리합니다. 따라서 기능=페이지로 명명 하겠습니다.
  • 해당 페이지 안에 페이지에서 이루어지는 작은 Component로 분리 하거나 페이지 내부에 모든 기능을 작성합니다.
  • 해당 페이지에서만 사용되는 Comopnent라면 Feature와 같은 레벨에 작성합니다.
  • 아래 예시 참고.
└── /src 
  ├── /components    (공통 컴포넌트 집합)
  ├── /views
	├── Todo        (Todo과 관련된 모든 기능)
		├── hooks   (Todo과 관련된 Hook)
			├── todo.hook.tsx     
		├── TodoItem.tsx           (Todo에서만 사용되는 Component)
		├── TodoForm.tsx           (Todo에서만 사용되는 Component)
		├── TodoProgressBar.tsx    (Todo에서만 사용되는 Component)
		├── Todo.tsx               (Todo의 Page)

...///

장점과 단점

  • 단점
    • Components Layer에 Component 규모에 대한 분류가 안되어있음.
    • Component들 끼리 스파게티처럼 엮여 있음.
      • Side Effect에 대해서 예측과 대응이 안됨.
    • FeatrueA와 FeatrueB딱 이 두 곳에서만 사용하는 공통 기능이 있는 경우 모호해짐..
  • 장점
    • 쉽습니다.
    • 명확합니다.
    • 하나의 디렉토리에서 주로 작업이 되어, 디렉토리 이동이 적습니다.
    • 미 사용 Code를 추적하기 용이합니다.
    • NextJS와 같은 React기반 SSR 프레임 워크와 동일한구조 !

🤔 Atomic Design

  • Component를 규모에 맞춰 5단계로 분해하는 방법입니다.
  • Atomic
    • 가장 작은 단위입니다.
    • Button 1개, Input 1개와 같이 독립적인 요소 1개로 구성된 Component입니다.
    • 재 정의된 요소도 여기에 포함됩니다.
  • Molecules
    • 분자라는 의미의 컴포넌트입니다.
    • 여러가지의 Atomic혹은 Custom Component로 묶여서 그룹을 이룬 Component입니다.
    • 주로 Header, InpitSet, Card와 같은 Compnent가 여기에 포함됩니다.
  • Organisms
    • 유기체 라는 의미의 컴포넌트입니다
    • 여러개의 Molecules, Atomic으로 구성된 컴포넌트입니다.
    • 유기체라는 의미에서 알수 있듯이 독립적인 기능을 갖을수 있습니다.
  • Template
    • Page를 이루는 레이아웃이 이루어지는 영역입니다.
    • Data를 Binding시켜서 Component가 되도록 추상화 하는 레벨입니다.
    • Template은 데이터는 가지고 있지 않지만 Page의 가장 가까운 Layout, Component의 집합입니다.
  • Page
    • Store, useState를 직접적으로 사용하는 영역입니다.
    • Routing된 Page에서는 Request를 발생시키고 Store에서 데이터를 dispatcher합니다.
    • response받은 데이터를 Templete의 props로 전달하여 페이지를 완성합니다.
└── /src 
  ├── /components    (공통 컴포넌트 집합)
		├── atomic
		├── molecules
		├── organisms
        ├── template
  ├── /views
		├── Todo
			├── hooks
				├── todo.hook.tsx     
			├── Todo.tsx               (Todo의 Page)

...///

장점과 단점

  • 장점
    • 공통 Component에 드디어 규모와 계층이 생겼습니다.
    • 변경 추적이 용이하고 Side Effect를 예측 할 수 있습니다.
    • 재정의어디서 이루어졌는지 명확합니다.
    • 테스트 대상이 명확함에 따라 Story book을 작성하기 명확합니다.
    • 작은단위로 분해된 컴포넌트는 CleanCode를 적용하기 용이합니다.
    • 작은단위로 분해된 컴포넌트는 SOLID 원칙을 적용하기 용이합니다.
    • 장기적으로 개발속도 가파르게 상승함.
  • 단점
    • 비약적인 코드량 증가
    • 모호함… 모호함.
    • 초기 개발 속도 느림
    • Depth가 너무깊다.

Atomic Design의 모호함에 대해서..

  • 모호함은 Template, Molecules, Organisms에서 왔다.
  • Templete은 결국 SmartComponent patten에서 featrue Componet가 해왓던 역활이랑 동일한 것 아닌가?
  • Molecules vs Oranisms
    • 분류의 모호함
      1. 몇 개의 컴포넌트 조합부터 Molecules와 Oranisms의 경계가 되는 것 인가…
      2. 컴포넌트 규모로 분리하자면 어느 규모가 경계가 되는 것인가.
      3. 유기체라는 이름처럼 기능이 정의에 따라 분류 된다면, 정의 된다면 개별동작을 정의해버리면 결국 페이지(기능)에 종속되는 것 아닌가? 그렇다면 component/organisms 에 있어야 하는게 아니고 view/featureA/organisms 이렇게 있어야 하는거 아닐까? 그럼 결국 이것도 Smart Component patten에서 featrue Componet와 같은거 아닐까?
      4. 개발자 마다 느끼는 규모와 컴포넌트 단위가 다름.
    • Page 개발에서의 모호함
      1. Template개발 중 A Component를 Import하였다. 이 Compnent는 Organisms일까… Molecules일까… 겉만 보고는 절대 알수 없다.

몇 가지 해결책에 대해서...!

  1. 팀원들과 협의를 통해서 명확한 경계를 정의하는게 중요하다.
    1. Molecules vs Oranisms를 명확하게 나눈다.
    2. 명명법을 잘 정의하여 Code레벨에서 혼동되지 않도록 구분한다. 하지만 이 경우 컴포넌트에 아키텍처 계층이름을 의미하는 명사가 접두,접미에 붙게 되어 Clean Code를 온전히 지키기 어렵다
  2. 격리
    • 비즈니스 규모에 맞춰 적절하게 아키텍처를 격리하였다. Naver D2 Atomic 회고를 보면 Atomic Design의 구성요소를 제거하여 개발하였다. 모호함 때문이었다. Atomic, Molecules, Page만 두고 개발하였다.

나의 경험에 의한 Atomic 디자인 후기

3개월, 18개월, 4개월짜리 프로젝트를 리딩하며 느낀 후기입니다.

  • 정말 모호하다.
  • 5Level을 모두 사용하는 것은 소,중규모 프로젝트엔 어울리지 않음.

⭐️ 새 프로젝트는 정리된 Atomic Design 으로

  • 결국에 Atomic의 Template은 Feature Component와 같지 않나 라는 결론에 도달하였습니다. 그래서 Template은 Feature Component와 같은 의미에서 Page 종속적으로 개발하는 것으로 정의 하였습니다.
  • 또한 Organisms은 모호함 때문에 제거 하였습니다.
  • 1개의 Component는 모두 Atomic입니다.
  • N개의 Component 집합은 모두 Molecules 입니다.
  • 레이아웃이 정의되거나 Page종속적으로 데이터를 추상화 해놓은곳은 feature입니다.
  • 라우팅을 받아 내는 곳은 Page입니다.

└── /src 
  ├── /components    (공통 컴포넌트 집합)
		├── atomic
		├── molecules                     
  ├── /views
		├── Todo
			├── hooks   (Todo과 관련된 Hook)
				├── todo.hook.tsx     
			├── TodoItem.tsx           (Todo에서만 사용되는 Component)
			├── TodoForm.tsx           (Todo에서만 사용되는 Component)
			├── TodoProgressBar.tsx    (Todo에서만 사용되는 Component)
			├── Todo.tsx               (Todo의 Page)

...///

참고사이트

https://ko.legacy.reactjs.org/docs/faq-structure.html (리엑트공홈 아키텍처)
https://ghost4551.tistory.com/255 (아토믹다지안 실제 사용경험)
https://yozm.wishket.com/magazine/detail/1531/

profile
hooeee
바구

0개의 댓글