저는 부업Findy 개발에 종사하는keik입니다.
며칠 전 그쪽 개발에서 스토리북을 도입했는데 도입만 하면 썩기 쉬운 스토리북이라고 생각했는데 이런 일이 생기지 않도록 여기서 조금 공을 들였습니다.제가 그 내용들을 소개하겠습니다.

TL;DR

UI 구성 요소의 디렉토리 도구 Storybook은 설계, 설치, 테스트의 모든 프로세스에 적합

단, 무심코 도입해도 유지되지 않고 썩기 쉽다

썩지 않도록 다음과 같은 조치를 취하는 것을 권장한다

StoryShots 가져오기 자동 스냅샷 테스트

Story는 각 UI 구성 요소 설치 파일을 파일 이름.stories.js으로 구현

파일 경로에서 Story 이름 자동 생성

샘플https://github.com/keik/maintainable-storybook-example

Storybook 개요

Storybook는 UI 구성 요소의 카탈로그 도구입니다.
Storybook의 시작 화면에서 React 등으로 구현된 UI 구성 요소의 렌더링 결과와 상호 작용을 확인할 수 있습니다.
Storybook에서 UI 구성 요소의 디렉토리를 Story라고 합니다.
추가된 Story 목록은 Storybook 화면에서 선택을 통해 표시 내용을 확인할 수 있습니다.
실물은 공식 견본을 보십시오.https://storybooks-official.netlify.com
Story의 추가 방법의 예로 Story에 이러한 UI 구성 요소를 추가MyUI하면 다음과 같습니다.
MyUI.stories.js

import { storiesOf } from '@storybook/react'
import MyUI from './MyUI'

storiesOf('Story名（任意の文字列）', module).add('default', () => (
  <MyUI>Hello Storybook</MyUI>
));

Story의 파일 이름은 *.stories.js로, 일반적으로 패턴을 통해 파일 이름을 일관되게 수집하여 Story에 자동으로 추가합니다.

Storybook 도입의 이점

스토리북을 가져오면 뭐가 좋을까요?
나는 대충 조목조목 써 보겠다.

카탈로그에서 UI 구성 요소를 찾아 재활용 가능

Storybook은 개발 중인 애플리케이션을 시작하지 않고 개별적으로 간단하게 시작할 수 있어 디자이너와 함께 작업하는 채널이 되기 쉽다

Story 설치가 UI 구성 요소의 사용법이 되는 문서

Story 설치 시 UI 구성 요소의 사용 편의성을 확인하고 인터페이스 설계를 검토할 수 있습니다.

부작용(Mount시 데이터fetch 등)이 있으면 스토리가 추가하기 어려워 부작용을 분리하는 디자인을 촉진했다.

HMR(Hot Module Replace ement)에 대응하여 코드 변경이 즉시 화면에 반영되어 설치 작업에서 신속하게 진행될 수 있음

추가된 Story의 스냅샷 테스트를 자동으로 구성

다 좋은 일이야.

근데 Storybook은 썩기 쉬워요.

그런 스토리북이라도 무심코 가져오면 유지되지 않고 썩기 쉽다.
스토리를 적절하게 관리하면 카탈로그의 일람성, 검색성이 사라지고 새로운 스토리 추가 시 유지보수 비용이 증가하며 양식의 재현성이 불완전하고 신뢰성이 떨어지기 때문이다.
원가가 장점을 초과할 때 그것은 썩기 시작한다.
따라서 유지보수 비용을 낮추면서 더 큰 이익을 누리기 위해 다음과 같은 노력을 기울여야 한다.

1. StoryShots의 자동 캡처 테스트 가져오기

Storybook에 추가된 Story에는 자동으로 캡처 테스트StoryShots가 가능한 Storybook adion이 있습니다.
이것을 가져오면 UI 구성 요소의 변경 사항에 대해 Story의 유지보수를 따라가지 않으면 Story가 표시되지 않는 것을 방지할 수 있습니다.
또한 스토리 추가 = 카탈로그 + 테스트를 추가하여 스토리 추가 효과를 추가합니다.캡처 테스트에서도 커버물을 측정하기 때문에 보면서 스토리를 추가하면 기분이 좋아진다.

2. Story 는 UI 구성 요소 설치 파일의 각 구성 요소에 대해 설치합니다.stories.js라는 파일 이름으로 구현

Story의 추가 방법과 파일 이름은 제한이 없지만 UI 구성 요소의 설치 파일과 같은 층에 같은 이름.stories.js 파일로 구성하는 것을 추천합니다.
이렇게 하면 파일 레이아웃에서 Story와 좌표 테스트가 존재하는 UI 구성 요소를 한순간에 파악할 수 있습니다.반면 이렇게 하지 않으면 추가적인 스토리에서 타깃의 구성요소를 찾거나 추가를 반복하는 일이 발생하기 쉽다.
이 정도면 됐어.

.
├── companies
│   └── components
│       ├── Company.js
│       └── Company.stories.js
└── users
    └── components
        ├── User
        │   ├── Profile.js  <------ Story 無い
        │   ├── Settings.js
        │   └── Settings.stories.js
        ├── User.js  <------------- Story 無い
        ├── Users.js
        └── Users.stories.js

3. Story 이름에서 파일 경로 자동 사용

Storybook의 Story 요약 표시 섹션은 Story 이름에 포함된 / 문자에 따라 자동으로 계층화됩니다.

UI 구성 요소를 쉽게 찾을 수 있도록 계층 구조는 위의 파일 레이아웃과 일치해야 합니다.
이때 파일 레이아웃과 일치하기 위해 스토리 이름을 수동으로 설정하는 유지 보수는 매우 번거롭기 때문에 스토리 설치 파일의 경로에서 자동으로 생성하십시오.
이 방법은 공식 문서에 소개되어 있다.
https://storybook.js.org/docs/basics/writing-stories/#generating-nesting-path-based-on-__dirname
이를 참고하여 Story 이름에서 파일 경로를 사용할 때 다음과 같은 방법을 사용할 수 있습니다.

import { storiesOf } from "@storybook/react";
import { base, filename } from "paths.macro"

storiesOf(`${base}/${filename.replace("stories", "")}`, module).add(...)

견본

위와 같은 스토리북이 설정된 샘플을 제작했기 때문에 가능하면 참고하세요.
https://github.com/keik/maintainable-storybook-example