[FE] 프론트의 디자인 시스템

[airman5573]

현재 공통 컴포넌트 분류 기준, 스타일 적용 방식 등 정립되지 않은 부분들이 있습니다.
어떻게 하면 좋을까요?

[airman5573]

오랜 대화 끝에 어느정도 결론에 도달했습니다!
자세한 내용은 추후 wiki에 기입하겠습니다 :D

디자인 시스템 정립 과정

[nan-noo]

좋습니다. 여기에 오늘 이야기한 것까지 추가로 더해서

• 6번은 필요할 때만 도메인에 맞게 랩핑하는 것으로 변경
• 왜냐하면 Divider, PageTitle, SectionTitle 등과 같은 예외가 발생하기 때문: 굳이 도메인 이름을 붙여서 한 번 더 감싸줄 필요가 없음
• 각자의 기준에 맞게 어떤 컴포넌트에 종속된 컴포넌트이지만 충분히 분리할만하다고 생각될 때 6번 규칙을 적용
• 예시: FilterSection 컴포넌트에 종속된 FilterButton 컴포넌트

  const FilterButton:React.FC<props 타입> = ({ 어떤 props들 }) => {
     return (<ToggleButton checked={isChecked} onClick={handleClick}>
        <Flex direction="column" width="80px">
           <Name>{name}</Name>
           <Description>{description}</Description>
         </Flex>
     </ToggleButton>);
  };

[nan-noo]

추가

• 상속은 props 자유도를 너무 많이 준다!
• 공통 컴포넌트는 custom props로 일부 커스텀할 수 있도록 한다. (미디어 쿼리, 애니메이션 등)
• custom prop은 제한된 속성만 받을 수 있다.
  • 타입 지정 + 런타임 속성 확인

[nan-noo]

custom할 필요 없는 기본 props들에 관해 이야기해보는 건 어떨까요?

[nan-noo]

• 과도한 컴포넌트 분리는 오히려 코드의 복잡성을 높임
  • 추가적으로 type, props를 작성해야 함 -> 코드 양 증가

  • 적절한 분리가 필요함!

[nan-noo]

컴포넌트 계층

1군

• 공통 컴포넌트
• 모든 도메인에 걸쳐서 사용되는 스타일 등(박스 버튼, 인풋)
• 예) 칩: 어느 도메인, 어느 페이지에서 사용되어도 상관 없음, 스타일만 고정
• -> 최상위 components 폴더에 생성

2군

• 페이지 또는 도메인에 종속된 컴포넌트
• 자신의 영역을 가지고 있는 컴포넌트(섹션, 컨테이너, 스터디 카드 등)
• 예) 스터디 칩: 여러 페이지에서 사용되고 있으나 스터디 도메인에 종속됨
• -> 페이지 내에 폴더를 만들고 생성

3군

• 2군 컴포넌트에 종속되고 재사용되지 않는 컴포넌트
• 주로 1군 컴포넌트를 기반으로 생성(물론 바로 구현하는 경우도 있음!)
• -> 2군 컴포넌트 폴더의 Atomics.tsx 파일에 모두 넣고 '무조건' 상대 경로로 import(항상 './Atomics.tsx' 경로)
  • 상대경로로 import 하는 이유
    • 3군에서 가져온 것임을 명시하기 위해
    • 외부에서 가져온 것이 아니고, 2군 컴포넌트 폴더에 종속된 컴포넌트를 가져온다는 것을 명시하기 위해서

승급

각 계층의 컴포넌트는 재사용성에 따라 다른 계층으로 승급 가능
예) 더보기 버튼

• 스터디 상세 페이지의 후기 섹션에 종속되었다가(3군) 스터디 멤버 섹션에도 사용되면서 2군으로 승급됨

[nan-noo]

%명심% 매번 승급 심사하기

[nan-noo]

폴더 구조

components/@shared

• 1군 컴포넌트만

components

• 여러 페이지에 사용되는 2군 컴포넌트(스터디 칩 등)

-> 나머지는 현재까지처럼 pages에 종속!

[airman5573]

제안 2 (위와 비슷)

컴포넌트 구조 개선

1. 컴포넌트 분리 기준

• 한 파일 안에 가능한 컴포넌트를 몰아 넣습니다(응집성).
  • DetailPage.tsx안에 하위 컴포넌트을 넣습니다.
• 하위 컴포넌트가 너무 복잡하거나 무거운 경우에는 컴포넌트를 분리합니다.
• 공통 컴포넌트는 src/components/@shared에 배치합니다.
• 페이지간 공유되는 컴포넌트는 src/components에 배치합니다.

2. 스타일링

• styled component를 사용하지 않습니다.
  • 의도치 않은 props가 들어갈 수 있기 때문입니다.
  • styled와 일반 컴포넌트를 구별할 필요가 없어집니다.
• layout은 flex를 사용합니다
• 스타일이 정해져 있는 컴포넌트는 css props를 사용해 스타일을 적용합니다.
• 공통 컴포넌트 혹은 스타일에 변화를 줄 수 있는 컴포넌트들은 외부에서 스타일을 주입받는 컴포넌트는 제한된 스타일만 넣을 수 있도록 강제합니다.

3. jsx 가독성 높이기

• jsx에 가능한 스타일 정보는 보여주지 않습니다.
• 해당 컴포넌트의 역할/기능이 들어나도록 합니다.

<Button type="button" variant="secondary" custom={{marginBottom: '10px'}} onClick={handleAddButtonClick}>
  추가하기
</Button>

가 아니라
<AddButton onClick={handleAddButtonClick} /> 을 만들어 사용합니다.
다시말해서 가능한 도메인을 입히고 스타일 정보를 숨깁니다.
이렇게 하면 해당 컴포넌트를 사용하는 쪽에서 한눈에 파악하기가 쉬워집니다.

• 조건적 렌더링은 즉시실행 함수를 활용합니다

return (
  <Card backgroundColor={theme.colors.white} shadow custom={{ padding: '40px', gap: '8px' }}>
    <Card.Heading custom={{ fontSize: 'xl', marginBottom: '10px' }}>
      {(() => {
        if (isRegistered) return <AlreadyRegistered />;
        if (!isOpen) return <Closed />;
        if (!enrollmentEndDate) return <Open />;
        return <EnrollmentEndDate theme={theme} enrollmentEndDate={enrollmentEndDate} />;
      })()}
    </Card.Heading>
    <Card.Content custom={{ fontSize: 'lg' }}>
      ...
    </Card.Content>
  </Card>
);

4. data와 컴포넌트 분리하기

• hook을 사용해서 가능한 컴포넌트에서는 view에 관한 정보만 담도록 하고, data에 관한 정보는 숨깁니다.

[nan-noo]

컴포넌트를 구분하는 기준은 정했지만, 각자가 실제 생각하는 범위가 주관적이기 때문에(이건 어쩔 수 없다고 생각합니다. 컴포넌트 분리에 표준이 있는 게 아니니까), 피그마나 지금 배포된 페이지를 보면서 어떤 컴포넌트를 분리할 것인지 지정하는 것도 좋을 것 같습니다.

원래 디자이너가 있다면 페이지가 미리 구성되어서 기능을 구현하기 전에 논의하기 쉬웠을 것 같은데, 초반에 피그마로 초안을 만들긴 했지만 기능이 조금씩 달라지면서 디자인도 그때그때 바뀌었기 때문에 기준이 달라진 것 같습니다.

지금 공통 컴포넌트는 충분히 분리된 것 같은데, 한 번 2군 컴포넌트를 같이 정해보는 것은 어떨까요?