Storybook 사용 후기
nextjs와 함께 스토리북을 사용하면서 느낀 점은 다음과 같다.
장점
1. 독립적인 UI 개발 환경의 존재
원래 같았으면 컴포넌트 하나를 개발하더라도 실제 페이지 위에서 다른 컴포넌트들의 배치를 신경쓰면서 개발했어야 했는데, 스토리북은 애초에 독립적인 개발 환경이 제공되기 때문에 이를 신경쓰지 않아도 됐다.
개인적인 생각에는 이러한 편안함이 Component Driven Development 접근법을 조금 더 쉽고 자연스럽게 실천할 수 있도록 유도하는 것 같다.
2. visual regression test 제공
프론트엔드 개발에 처음 입문하는 순간부터 고질적으로 괴롭힘 받아온 부분이 UI가 깨지는 부분이었다. 이는 최대한 컴포넌트화하면서 조심조심 개발해도 100% 막을 수 없었고, UI가 깨지는지 확인하는 것 역시도 매우 피로한 일이었다.
그런데 스토리북이 제공하는 chromatic의 visual regression test를 통해 UI가 깨지는 부분을 쉽게 필터링 및 수정이 가능했다.
단점
셋업과 관련하여 자잘하게 신경써야 하는 점들이 존재한다.
컴포넌트들이 실제로 사용되는 애플리케이션의 구조와 스토리북 내에서 렌더링되는 화면의 구조는 다르다. 그도 그럴것이 스토리북은 iframe 내에서 렌더링하고, <div id="storybook-root">태그가 존재하는 등 계층 구조가 동일하지 않기 때문에 preview-head.html등을 통해서 실제 app과 렌더링되는 환경이 최대한 비슷해지도록 스타일을 수정해주어야한다. 예를들면 full-screen을 만들어야 하는 경우가 있겠다.
이외에 render 프로퍼티 내에서 setState를 사용하는 경우 린트 에러를 억제하기 위해 함수 선언문을 사용해야 한다던지, styled component에서 theme provider를 제공해야 하는 경우에 React.createElement를 사용해야 하는 번거로움 등 에러 해결 및 셋업과 관련해 자잘하게 신경써야 하는 부분들이 존재한다. (후자의 경우 과거에는 있었으나 최신 버전에서는 해결된 것으로 보인다.)
물론 얻는 장점들을 생각하면 앞선 단점들은 충분히 감내할만하다.
소소한 팁
카테고리별로 서로 다른 layout을 적용하고 싶을 수 있다. 예를들면 다음 상황과 같다.
개발하는 사이트에 존재하는 페이지들은 모두 화면의 정 가운데에 보여진다고 가정하자(mx-auto 적용). 그리고 이 페이지들은 스토리북에서 PAGES라는 카테고리 하위에 존재하게된다. 스토리북에서 보여질 때도 당연히 화면의 정 가운데에 보여진다. 하지만 ATOMS 카테고리에 해당하는 컴포넌트들은 스토리북에서 보여줄 때 평범하게 11시 방향에 배치됐으면 좋겠다. 이 경우 카테고리별로 다른 Layout이 적용돼야 할것 같다.
요 경우 Decorator를 통해서 다음과 같이 우회하여 구현할 수 있다.
우선 스토리 내 meta 객체의 parameters에 position 필드로 center를 삽입하고,
const meta = { parameters: { position: "center", }, // ...이하 생략 };
다음과 같이 preview 내에서 context에 접근하여 position 필드가 center인 경우에만 가운데로 보내는 wrapper를 스토리에 래핑해주면 된다.
const preview = { decorators: [ (Story, context) => { if (context?.parameters?.position === "center") { return ( <CenterWrapper> <Story /> </CenterWrapper> ); } return <Story />; }, ], // ...이하 생략 };
공식문서에 context를 이용한 예제가 존재하지 않아서 팁이되지 않을까 싶어 공유한당.