Skip to content

Latest commit

 

History

History
171 lines (117 loc) · 7.72 KB

README.md

File metadata and controls

171 lines (117 loc) · 7.72 KB
Raw

기술 스택

  • react
  • typescript
  • emotion
  • storybook
  • lint

조기 종료

네이버에서 사용되는 ui 구조가 재사용되는 게 아니라 각각의 UI들이 목적에 맞게 설계된 것을 알 수 있었음
네이버는 디자인 시스템을 적용하기에는 패턴이 너무 다양하다
분석하고 제작 하면서 원하는 성과를 달성함

네이버 클론코딩
스토리북

성과

  • 요구사항에 맞는 개발 + 관리하기 용이한 개발 패턴 ( 잘 정리된 입출력 패턴 )
  • 언제든지 다시 개발할 수 있는 잘 정리, 분할 된 디자인 시스템
  • 피그마 토큰 개발 보조 도구

새로 알게 된 것

  • ui에 대한 좀 더 섬세한 조작이 가능해짐 > padding , margin -값을 사용해서 html으로 인식되는 사이즈 조절

  • 피그마의 token-studio 플러그인에 대한 실 사용 경험

    어떻게 관리하는게 사용성이 높아지는지 확인할 수 있었음

  • 제작한 프로그램의 실용성 테스트 , 개발 방식 비교 ( 막 코딩, 시스템 기반 코딩 )

  • 스토리북 사용 경험

    확실히 유용하다 플러그인 없는 건 조금 아쉽다

  • 컨벤션 검증 성공

  • 피그마로 안되는 것을 알아냄

    • border-box 걸고 padding, width 계산 해야 피그마 호환된다
    • border-box와 맞는 width 100%를 나오게 하려면 모든 것에 써야한다

평가

  • 컬러칩이나 디자인 시스템의 단위가 제대로 확립되지 않은 점이 아쉬움
  • 개발 전에 미리 사이트맵 데이터를 만들면 좋을 것 같다
    • ( 버튼 이름, 링크 , 식별명을 미리 정하고 들어가는게 맞는 것 같았음 , i18n으로 검색하면 스파게티 코딩을 찾을 수 있음 )
    • i18n같은 걸 개발 도중에 만들기에는 위험 부담이 크다 ( 기존 시스템을 갈아 엎어야하는 문제가 생길 수 있음 )
  • 아토믹한 개발 방식이 typescript 와 react의 이해도를 높이고 구조적으로 보는 것에 도움이 됨
    • 타입 선언과 설명을 잘 해야 상위 컴포넌트를 작업하면서 하위 컴포넌트의 기능을 이해하기 때문
  • 디자인 시스템을 위해서 재사용되는 ui 구조 설계가 잘 되면 좋겠다는 생각이 듬
    • 네이버의 경우
      • 재사용되는 ui가 거의 없고, iframe으로 관리되는 영역도 있고
      • 수작업으로 ui들의 위치를 강제로 잡아둔 적응형 페이지였다

개선 필요

  • stories 와 컴포넌트가 같은 폴더에 있는 것의 관리가 어려워질 수도 있어보인다

    • 기획 문서가 유기적으로 연결되있거나 , 플러그인으로 vscode에 바로 접근하면 단축가능해보임

    페이지 단위가 가장 만만한게 맞긴 하지만 서로 다른 페이지간에도 쓰라고 디자인시스템이 있는것이라...

    atoms 내에서도 다른 atoms를 쓰는 atoms 이 있는데 그럴 경우 폴더를 만들어서 철저하게 분리하는 것도 고려해볼만하다

    아직까지는 스토리북으로 조회해서 제어하는 것도 괜찮을 것으로 보여짐

클론 코딩의 목적

디자인 시스템을 관리되는 네이버 클론 코딩

효율적인 디자인 시스템을 구축하는 것이 목적

관리가 잘되는 프로젝트 구성을 위해서 준비한 것

  • 컨벤션
  • 코드 스타일 ( 로직 작성 스타일 정의 )
  • 디자인 구축 가이드 라인이나 시스템

디자인 구축 가이드라인

  • 컴포넌트 단위의 정의
  • 디자인 컴포넌트와 통신 모듈을 분리한다
  • 리덕스를 쓰는 패턴 역시 Result로 분리해서 사용한다
  • 재사용 컴포넌트가 많이 들어있는 components 를 @@로 명칭함

folder structure

  • atoms, modules, organisms , clusters , templates는 디자인컴포넌트이며 순서대로 컴포넌트의 크기가 커진다

    • 단위가 올라가다가 상호작용이 필요없는 결합도에 도달하면 ( 온전한 모듈이 될 경우 )
      배치하기 편한 형태로 css 작업을 하고 , 위치 조정 스트립트를 작성

    • 문서화를 베이스로 하기 때문에 이름 또는 storybook 코드를 통해 위치를 찾을 수 있게 하는 것을 목표로 함

    • 편의성으로 순서의 표시를 위해 stories 내부에서는 title에 01_atoms , 02_modules 를 작성 ( 넘버링 안써도 정렬되게 수정 될 경우 그걸로 변경 )

Result

  • 로직은 result에 작성한다 컴포넌트별로 관리되는 상태를 Result로 전달하여 실행하는 패턴
    • 관리되는 데이터는 state로 관리되기 때문에 모든 데이터는 이동이 자유롭다라는 것을 전재로 한다
    • 디자인 컴포넌트 재사용성을 끌어올리기 위해 로직의 분리를 강제하는 구조
    • 기능을 실행하는 컴포넌트에 미리 Result를 받게하고 Result를 Props로 받게해서 아토믹한 컴포넌트들을 사용할 수 있게 함
    • 하위 로직에게서 인터페이스의 입력결과를 끌어올리도록 하는 로직을 넣게해서 Result 사용을 최소화함

상위 컴포넌트에게 type 정보 전달 방법

현재 알고 있는 가장 간단한 방법은 사용한 type을 export해서 상위 컴포넌트에서 읽어볼 수 있게 하는 것이다

export type Props = {
  iconSet: IconSet
  setResponse?: React.Dispatch<React.SetStateAction<string>>
}

export type IconSet = {
  link: string
  text: string
  iconCSS: string
  size: string
}

Result 와 setResponse

디자인 컴포넌트의 필수 속성 끌어올리기랑 인터페이스에 로직 실행하게하는 것을 넣을 수 있다 setResponse는 어떤 인터페이스가 실행됬는지 ( 1, 2, 3 중 무엇이 실행됬는지 ) 파악하는 것에 쓰고 Result는 props를 받고 돌아가는 내부 로직이 Result를 실행시키는 구조로 사용

setResponse는 하위 디자인 컴포넌트의 실행 결과를 반환 받기위해 하위컴포넌트로 전달한다 결과 구분에 필요한 고유 값을 반환받는다 Result는 하위 컴포넌트가 결과 이 외에 다양한 값을 받는 코드일 경우 그 다양한 값으로 실행될 기능을 정의한다

피그마 토큰 플러그인에서 에셋 이름 설정할 때

ui에서는 color나 spacing이 구분되어있지만 변환 결과물인 css에서는 그렇지 않기 때문에 네이밍부터 color면 color.red.100 이런식으로 충분히 구분 가능하게 할 것

피그마에서 사용되지 않는 값은 other에 넣는다

디자인 시스템 컨벤션

상태관리 컴포넌트와 디자인 컴포넌트로 분리

리덕스나 리코일 같은 상태관리라이브러리를 디자인 컴포넌트 내에 넣지 않기

상태 관리 컴포넌트와 디자인 컴포넌트의 분리 이미지를 넣고 싶으면 추상화 시킨 컴포넌트에 이미지 링크를 넣어서 올려라

장점

  1. 디자인 컴포넌트의 재사용이 쉬워진다
  • 종속성이 없어져서 다른 곳에 옮겨 설치해도 설정할 게 없다
  1. 해당 컴포넌트에 대해 사용되는 값들을 상태관리 컴포넌트에서 한번에 볼 수 있다
  2. 스토리북이 된다

단점

간단한 걸 만들 때도 상태값을 써야할 때를 판단해 만들어야 한다 인터페이스의 기능 정의가 먼저 나와야 제작에 완성도가 높아진다

스토리북은 stories 로 이동

스토리북 내에서만 사용되는 리소스는 assets 에서 관리 ( ex: 테스트 리소스 )

적용되지 않음 상향식 개발을 하면서 main에 컴포넌트를 올리지 않고 , 스토리북에서 올려서 작업했고 그 과정에서 폴더 위치가 달랐으면 동선이 불편해졌기 때문