104%

잘 운영되고 있는 프론트엔드 코드 전체를 한번에 바꾸는것은 불가능하다. 천천히 하나씩 바꿔야한다. 왜 그렇게 해야하나? 많은 코드를 한번에 리팩토링하는것은 큰 위험부담이 따르기 때문이다. 다만, 리팩토링 기간이 길어질수록 두가지 application을 유지보수해야하는 기간도 늘어나며 이 리팩토링 기간에는 리액트의 완전한 장점을 누리지 못한다는 점을 감수해야한다. 현 상황 가정 당신은 서버사이드렌더링 방식으로 제공되는 HTML을 통해 고객들에게 서비스하고있다고 가정한다. 자바스크립트로 DOM을 조작하는 현재의 방식은 어플리케이션의 전체 상태를 관리하지 않는다. 그저 DOM에 직접 접근해서 하나하나를 수정할 뿐이다. 그래서 서버에서 받아온 데이터와 UI를 일치시키는 과정이 매우 까다로운 상태다. 그리고 가끔..

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