언어

TypeScript

프레임워크

React

고려한 후보

• Next.js

선택한 이유

• Next.js 러닝커브가 꽤 소요될 것으로 예상
• 6기 크루들이 레벨 3부터 유지보수 및 기능 개발을 진행할텐데, 5기 기준으로 레벨 4에 Next.js 를 학습함.

스타일링 라이브러리

Emotion/react Emotion/styled

고려한 후보

• Module CSS (CSS-IN-CSS)
• Styled Components (CSS-IN-JS)

선택한 이유

• 동적 스타일링 측면에서 Css-in-js 방식이 나은 선택, 따라서 Module CSS는 제외
• 현재 Styled Components와 Emotion 간의 기능 차이는 거의 없다
• 그러나 Emotion 이 styled components 보다 가볍다
  • Styled components: 1.65 MB
  • Emotion/react + Emotion/styled: 584 kB + 177 kB = 761kB

문서화 도구

Storybook

선택한 이유

• UI 문서화
• 다른 분야 팀원과 원활한 협업에 도움이 됨

테스트 도구(자동화)

Jest React Testing Library

고려한 후보

• Cypress
  • e2e 테스트 같은 경우는 QA가 있기 때문에 불필요하게 cypress는 작성하지 않음

선택한 이유

• 스토리/인수조건 검증을 위해 컴포넌트 단위의 테스트를 작성한다.

서버 API Mocking 도구

MSW

고려한 후보

• Json Server
• Mockoon

선택한 이유

• 시간이 촉박하기에 익숙한 MSW (러닝커브가 거의 없음)

번들링 도구

Webpack

고려한 후보

• ESBuild
• Vite

선택한 이유

• 원하는대로 커스터마이징이 가능하다는 장점
• 트러블슈팅 과정을 겪으며 번들링 이해도를 높임
• Webpack 은 공식문서/커뮤니티가 잘 되어 있다.

HTTP 클라이언트

fetch API

고려한 후보

• Axios
• Ky

선택한 이유

• Axios나 ky와 같은 라이브러리를 사용하면 편리하지만, 인수인계를 위해 native한 fetch API를 사용

서버 상태 관리 라이브러리

미정

고려한 후보

• SWR
• React Query

미정인 이유

• 필요할 때 도입
• React Query VS SWR
  • 비교적 간단한 애플리케이션: SWR
  • 복잡한 애플리케이션: React Query
  • 현재는 간단한 애플리케이션이지만, 후에 도메인이 추가되며 복잡해질 가능성이 높기 때문에 도입한다면 React Query 를 선택

전역 상태 관리 라이브러리

미정

고려한 후보

• Context API
• Recoil
• Zustand

미정인 이유

• 아직 전역적으로 관리할 상태가 없다.
• 서버 상태 관리 라이브러리를 사용할 때, 전역 상태 관리 라이브러리를 도입할 이유를 잘 느끼지 못함