storybook

어떻게? 왜 작동하는가? 자 이전글에서 모노레포에서 tsconfigPath의 마법 같은 경로문제 해결 기능을 보았다. 하지만, 개발자라면 마법과 같은 일은 없으리라는 것을 알고 있을 것이다. 결국 왜? 를 알아야 내 것이 되는 것이다. 어떻게 tsconfigPath가 경로문제를 해결했는지 확인해보자. 바쁜 분은 결론만 보아도 이해에 도움이 될 수 있을 것 같다. viteFinal .storybook/main.ts의 viteFinal은 vite-builder를 통해 storybook을 구성하는 경우에 사용되는 옵션이다. 추가적인 플러그인을 적용시키는게 가능하다. 즉 아래 코드는 기존 storybook vite의 config를 가져와서 tsconfigPath plugin을 적용시킨 후에 merge하고, 이를..

이전 게시글에서 UI테스트를 하기 위해 Storybook을 도입했다. 각각의 프로젝트마다 각각의 컴포넌트 테스트를 해볼 수 있어서 좋을것이라 판단했다. 하지만 문제가 있었다. 배포가 너무 많다. 3개의 배포 3개의 레포에 대해서 chromatic을 통해 storybook을 각각 배포하다보니 두가지 문제가 발생했다. 테스트하기 힘들다. 배포 완료된 링크가 3개라 일일히 들어가서 테스트해봐야한다는 단점이 있다. 속도가 느리다. 위 사진처럼 순차적인 형태로 각각의 레포 storybook을 배포하다보니 2분씩, 총 7분가까이 걸리는 문제가 발생했다. 심지어 이 CI는 pull_request마다 돌아야하므로 더 자주, 더 많이 호출되어야한다. 또 우리 레포는 현재 4개의 프로젝트로 구성되어있고, 추후에 더 추가될..

이제 프로젝트는 앱 런칭을 앞두고 QA를 진행하고있다. 이렇게 QA를 진행하다보니 알게된 것은 생각보다 다양한 기기에서 테스트하다보니 UI가 깨지는게 많다는 점이었다. 그러나 의외로 UI 깨지는 것을 쉽게 해결하기가 쉽지않았다. 아래와 같은 이유들 때문이었다. 특정 사이즈에서만 깨진다. 아래와 같이 화면이 좁아지면 UI가 깨진 다던가... 문제가 있었다. 반응형 사이즈 테스트를 해볼 수가 없다. 서버 API호출을 줄여 운영 비용을 줄이기 위해 네이티브 DB를 사용하기로 결정했었다. 사용자가 쓴 글, 좋아요 누른 글 등을 앱 내부 DB에 저장하게 하고, 로그인시 서버와 1회 통신을 통해 동기화하는 형태로 서비스를 구성했다. 이렇게 앱 내부 DB를 사용하는 곳이 늘어나다보니 이제는 브라우저로 배포된 서비스 ..