Develop/4th week

[cla6shade]

4주차 PR

멘토님께 받은 피드백을 바탕으로 아래 내용을 구현했습니다.

1. feature-sliced design에 근거하여 모듈 참조 규칙을 설정했습니다.
2. CI workflow를 설정하여 테스트를 자동화했습니다.
3. fsd 폴더 구조를 아래와 같이 정리했습니다.

Feature-sliced Design

규칙들

• feature-sliced는 기본적으로 계층형 구조를 가집니다.

• 각각의 플더에 들어갈 내용은 아래와 같고, 계층적 구조를 갖습니다.

  • app: 전역 컴포넌트 (ex. GlobalStyle, ChakraProvider 등)
  • pages: 라우터를 통해 렌더링할 페이지 컴포넌트
  • entities: 비즈니스 엔티티. 사용자 정보, request type 등
  • widgets: pages에 사용되는 독립적인 UI 컴포넌트. 굳이 따지자면 atomic design의 organism과 비슷한 듯.
  • features: 비즈니스 로직. (ex. 로그인 시 비밀번호 검증, form validation, 상품 주문하기 등)
  • shared: 재사용 할 수 있는 UI, hooks, utils 등. 비즈니스 로직과 분리된 것들. (ex. axios instance 등)

• 하위 계층의 모듈에서는 상위 계층의 모듈을 참조할 수 없습니다. (ex. entities 내부 모듈은 pages의 모듈 참조 불가능)

• 각각의 계층은 slice라는 하위 요소를 가집니다.

  • slice는 각 계층을 비즈니스 영역별로 쪼개는 역할을 합니다.
  • 그 예시는 아래와 같습니다.
  • 

• slice는 segment로 구성됩니다. 일반적으로 사용되는 세그먼트들은 다음과 같습니다.

  • api - 필요한 서버 요청.
  • UI - 슬라이스의 UI 컴포넌트.
  • model - 비즈니스 로직, 즉 상태와의 상호 작용. actions 및 selectors가 이에 해당
  • lib - 슬라이스 내에서 사용되는 보조 기능.
  • config - 슬라이스에 필요한 구성값이지만 구성 세그먼트는 거의 필요하지 않음.
  • consts - 필요한 상수.

• 각 slice와 segement에는 index.ts라는 모듈을 통해 외부로 공개됩니다.

  • index.ts에서 export되지 않는 내부 모듈은 외부에서 참조할 수 없으며, 이 규칙은 @feature-sliced를 통해 설정했습니다.

    
    // good
    import { Button } from '@shared/Button';

  // bad import { ButtonInternal } from '@shared/Button/Button';

  // good import { Button } from './Button';

  // bad import { ButtonInternal } from './Button/Button';

• import order

  • 각 모듈은 import 순서가 있고, 높은 계층 -> 낮은 계층의 모듈 순으로 import해야 합니다.
  • 다만 이는 airbnb code convention과 충돌할 수도 있으므로, 추후 구현하면서 논의가 필요합니다.