Storybook에서 API 호출을 조롱하는 방법

다른 날 나는 스토리북 페이지 구성 요소를 구축하고 있었고 페이지에 상태를 채우기 위해 개발 환경에서 API를 적중하는 useEffect 후크가 있는 문제가 있었습니다. 내가 되찾는 데이터에 Id가 필요했기 때문에 이것에 몇 가지 문제가 있었습니다. 그래서 Id와 관련된 레코드를 찾기 위해 데이터베이스에서 조회할 수 있었습니다.

내 이야기를 웹사이트에서 볼 수 있는 방식으로 만들 수 없었기 때문에 이것은 나에게 몇 가지 빨간색 경고를 주었습니다. 이 블로그 게시물은 구성 요소가 API와 함께 작동할 때 스토리를 풍부하게 하고 더 효과적으로 만들기 위해 이 문제를 해결하는 방법에 대한 것입니다.

왜 스토리북용 dev API를 사용하면 안되나요?

페이지 상태 유지

되돌아오는 데이터를 제어할 수 없기 때문에 여러 페이지 상태를 유지하기가 매우 어렵습니다. 따라서 해당 API에서 오류를 표시하고 싶다면 백엔드 API가 되돌아오는 것을 제어하기 때문에 쉽게 그렇게 할 수 없습니다.

데이터베이스에 대한 종속성

기록이 삭제되어 스토리가 손상될 수 있습니다. 시각적 회귀 테스트가 있는 경우 선택되지만 그렇지 않은 경우 스토리가 작업되는 빈도에 따라 잠시 동안 스토리가 깨질 수 있습니다.

백엔드가 소비할 실제 데이터 필요

백엔드 API에는 본문에서 보내는 데이터에 대한 특별한 요구 사항이 있지만 우리가 관심을 갖는 것은 페이지가 처리하는 다양한 유형의 응답이며 우리가 제어할 수 없을 때 수행하기 어려운 것입니다.

스토리북 미들웨어

스토리북에는 스토리에서 사용할 수 있는 API 호출을 설정할 수 있는 기능이 있습니다. 내부적으로 미들웨어는 expressJS 서버이므로 구문이 정말 간단합니다. 예를 들면 다음과 같습니다.

.storybook/middleware.js

const express = require('express');
const bodyParser = require('body-parser');
​
​
const expressMiddleWare = router => {
    router.use(bodyParser.urlencoded({ extended: false }));
    router.use(bodyParser.json());

    router.get(/api/get-orders/:orderId, (request, response) => {
      if (request.params.orderId === 'error') {
        response.status(500).send('Something broke!')
      }

      res.send({ data: { text: 'hello world' } })

    })
};
​
​
module.exports = expressMiddleWare;

그리고 스토리북에 API 설정이 있습니다. localhost:9001/api/get-orders/123에서 상대 경로에 도달하면 성공으로 응답하고 localhost:9001/api/get-orders/error를 보내면 API에서 오류 상태를 강제 실행하므로 페이지 구성 요소에 대해 두 개의 스토리를 만들 수 있습니다. 다음은 귀하의 이야기에서 어떻게 보일지에 대한 예입니다.

export const withSuccessfulOrder = () => <Comp orderId="123" />
export const withErrorOrder = () => <Comp orderId="error" />

취급 환경

일부 웹 사이트는 dev/staging/prod와 같은 여러 api 환경을 갖는 경향이 있으며 일반적으로 api 도메인을 정의하는 환경 변수가 있습니다. 따라서 로컬에서 프론트엔드가 개발 환경에 도달할 수 있으며 해당 코드가 prod에 들어갈 때 api url은 이제 prod 도메인이 됩니다. 일반적으로 코드에서 다음과 같이 표시됩니다.

fetch(`${API_URL}/get-orders/${orderId}`).then((res) => res.json())so on...

스토리북에서 스토리를 함께 빌드할 때 기본 환경은 api 또는 미들웨어에 설정한 URL로 변경해야 코드가 API_URL을/api로 대체합니다. 이를 수행하는 쉬운 방법은 스토리북 build/serve 명령을 실행할 때 env를 설정하는 것입니다.

API\_URL=/api storybook build

그런 다음 env var를 참조하는 코드는/api가 되고 예제는/api/get-orders/${orderId}가 됩니다.

결론

그 정도야! 이제 훨씬 더 역동적이고 웹사이트에서 테스트하기 전에 개발을 확장하는 데 도움이 되는 더 효율적인 스토리를 작성할 수 있습니다. 스토리북에서 API를 조롱할 때의 이점은 다음과 같습니다.

상태는 우리가 제어하므로 API에서 돌아올 것으로 예상되는 데이터를 전송하여 스토리를 더 정확하게 만들 수 있습니다.

변경되지 않고 모의 API가 넘어지거나 백엔드 API에서처럼 동작이 변경되지 않습니다.

개발자와 API 계약이 이루어지면 서로 의존하지 않고 동시에 작업할 수 있습니다.

시각적 회귀 테스트가 더 정확합니다.