104%

atomic design을 알게 되고 실제로 적용하려고 하니 애매한 부분이 너무 많았습니다. 1. html태그당 atom 한개를 만들어야 하는데 그럼 모든 html 태그에 대해서 atom을 만들어야 하는 것 인가? 2. atom, molecules, organisms등은 재사용의 가능성을 높이기 위해서 컨텍스트를 배제해야 하는가? (예를들면, UserList라고 하는 molecule이 아니라 User라는 Context를 제외하여 컴포넌트를 List로 작성하는것.) 3. molecule과 organism의 경계는?? 4. 어플리케이션의 상태는 어디부터 들어가야하는가? 이러한 궁금증을 해결하기 위해 이 개념을 만든 bradfrost가 직접 쓴 글을 번역했습니다. 아토믹 디자인 창시자 bradfrost의 글 ..

아토믹 디자인은 컴포넌트를 5개의 단계로 나눈다. Atoms(원자) button, icon, input등과 같이 컴포넌트의 최소단위를 의미한다. (보통 HTML 태그가 원자의 단위가 된다.) 원자는 컬러, 폰트, 애니메이션등을 포함한다. MoleCules(분자) 원자를 결합하여 분자를 만든다. INPUT 원자와 BUTTON 원자를 합쳐 검색창 분자를 만들수있다. Organisms(유기체) 분자들을 결합하면 유기체가 된다. 검색창 분자와 메뉴 분자 두개가 합쳐서 헤더라는 유기체를 만들었다. 유저는 유기체 단위로 사이트를 인식하기 시작한다. 유기체는 독립적이어야 하며(standalone), 쉽게 여기저기 옮길수 있어야하고(portable), 재사용(reusable)이 가능해야한다. Template(템플릿) ..

스토리북으로 UI 컴포넌트들을 정리하려고 하는데 어떤식으로 컴포넌트들을 분리해야하고 관리해야하는지에 궁금해서 정리하게 되었습니다. 본인이 알고 있는 좋은 구조가 있다면 댓글로 알려주시면 감사하겠습니다. 서론 나는 스토리북을 3년간 사용해왔다. 잘 구조화 하지 않으면 스토리북이 별로 유용하지 않다고 느껴 효율적인 구조를 찾아왔다. 내가 생각하는 스토리북의 best practice를 공유하겠다. 이 스토리북을 누가 쓸건가? 스토리북을 팀내에서만 쓸건지, 디자인 시스템 구축용으로 사용하여 외부에서도 같이 사용할건지에 따라서 프로젝트 구성이 달라진다. 외부에서도 사용해야 하는 경우 컴포넌트의 API를 상세히 작성해야 한다. https://github.com/intuit/storybook-addon-sketch ..