Frontend 기술 스택

프론트

현재 도입한 기술

• react

  • v18 (최신버전)
  • react-router - 라우팅
  • react-dom

• css

  • styled-component
  • 상호 작용이 많은 화면에 효과적인 CSS 라이브러리임
  • 컴포넌트에서 전달하는 값에 따라 동적으로 스타일을 적용할 수 있음.
  • css conflict의 발생을 줄일 수 있음
  • 일반 html tag를 개발자가 시맨틱하게 정할 수 있음

• test

  • storybook
    • 컴포넌트 주도 개발을 위해 storybook을 선택함
    • 컴포넌트별로 다양한 state를 확인할 수 있음
    • 기획자나 백엔드 등 다른 분야의 사람들에게 문서화된 결과물을 보여줄 수 있음
  • jest/react-testing-library
    • hook 등 상태 관리 관련 로직을 테스트함

• react-query

  • 서버와 통신하여 받는 데이터(response 데이터)가 많음
    • 단, 서버에서 실시간으로 동기화해야 하는 데이터인 경우 react-query를 사용하고, 그렇지 않다면 fetch 내장 함수를 사용하기로 한다.
  • 데이터가 오래되거나 mutation이 있다면 자동 updating을 지원함
  • 데이터가 오는 동안 pending 상태인 것을 알려주는 기능이 있어 이를 활용하여 선언적 코드 구성을 할 수 있다.
  • react-query를 사용하지 않고 직접 라이브러리를 만든다면 로딩중, 에러인 것, 데이터를 커스텀 훅으로 만들어 따로 테스트하는 과정을 거쳐야하여 시간이 소요될 것입니다.
  • 마찬가지로 캐싱을 하는 기능을 따로 개발하여 테스팅하는 과정을 거쳐야 합니다.
    • 캐싱은 이전에 요청한 데이터를 메모리에 저장하여 데이터를 다시 불러와야 할 때 서버에 다시 요청하는 대신 캐시에서 데이터를 반환하는 기능입니다. 따라서 react-query의 캐싱 메모리 지속 시간 설정과 다시 패치하는 시간을 설정하여 네트워크 요청 수를 줄여 성능을 향상할 수 있고, 사용자 경험을 개선할 수 있습니다.
  • 무한 스크롤을 하는 기능을 제공합니다
    • 페이지네이션이 아닌 무한 스크롤로 컨텐츠를 불러와야 하는 경우, 서버의 데이터를 상태화하는 작업이 지속적으로 이루어져야 합니다.
    • 무한 스크롤은 모바일 타겟으로 지정한 사용자들이 편하게 새로운 콘텐츠를 제공할 수 있기에 필요하겠습니다. 무한 스크롤을 react-query를 이용하지 않고 직접 구현하여도 되지만 , 직접 구현할 경우에는 페이징 처리, 서버 요청 관리 등 모두 직접 구현해야하므로 개발 시간과 노력이 더 필요하겠습니다. 따라서 직접 개발하기보다 이미 많은 개발자들이 테스트까지 마친 react-query의 기능을 이용하여 직접 구현할 시간을 다른 기능 개발에 시간 투자하여 저희 서비스의 완성도를 늘리는 방향으로 하려고 합니다.
  • query key를 사용하여 데이터 상태를 계층화해서 볼 수 있습니다.
  • 투표 선택지 수정의 경우 낙관적 업데이트로 사용성을 증가시킬 수 있습니다. 미리 투표 선택지 수정이 된 화면을 보여주고 통신에 실패한다면 이전 결과값으로 되돌리며 에러 메세지와 함께 사용자에게 보여줄 수 있습니다.
  • 게시글 목록이 있을 때 투표 선택을 하면 게시글 목록이 리렌더링 되는데 이 때 useMutate를 이용하여 성공 여부를 통해 캐싱 메모리를 변경하여 사용자가 화면을 새로고침하지 않더라도 즉각적으로 데이터가 변하게 되어 사용자 경험을 좋게 할 수 있습니다.

• msw

  • 백엔드와의 효율적인 협업을 위한 장치
  • 백엔드와의 통신(성공/로딩/실패)을 모의로 테스트할 수 있음
  • msw로 가짜 데이터로 이루어진 화면을 사용자 시점에서 테스트할 수 있음
  • 필요에 따라 실제 서버의 데이터에서 필요한 테스트는 비로그인 상태에서 진행할 예정

추후 도입할 기술

• recoil

  • 사용할 곳 : 유저 정보(포인트, 권한)
  • recoil은 컴포넌트 간의 상태를 전역으로 관리하려고 할 때 사용합니다. 전역으로 관리할 상태는 사용자 정보(이름, 포인트), 권한 정보(어드민인지, 일반 사용자인지), 알림 정보(새로운 알림이 도착했을 때 전역 상태로 관리하여 다른 컴포넌트에서 알림을 표시) 등에 사용하려고 합니다.
  • context api로 recoil을 대체할 수 있지 않을까요?
    • 대체할 수 있습니다. 그러나 저희가 recoil을 사용하는 이유는 다음과 같습니다.
    • recoil은 상태 변경 시 영향을 받는 컴포넌트만 재 렌더링하여 불필요한 렌더를 방지할 수 있습니다.
    • recoil은 간편하게 전역 상태를 공유하고 업데이트할 수 있는 훅을 제공합니다.
    • recoil은 상태 관리를 한 곳에서 집중적으로 할 수 있게 도와줍니다. recoil은 상태의 변화를 추적하는 기능을 제공하여 코드의 가독성과 유지 보수를 보다 쉽게 할 수 있습니다.

• cypress

  • E2E 테스트 툴 중 익숙한 툴을 선택함
  • 어플리케이션의 흐름과 사용자의 상호작용을 시나리오별로 테스트할 수 있음
  • 개발자가 사이트를 테스트 한 것이 기록에 남고, 다른 개발자가 시나리오를 읽고 이해할 수 있는 문서의 기능을 할 수 있다.

논의한 내용

• 테스트 도구가 많은데 모두 적절한 관리/수행이 가능한가요?
  • 프로젝트 규모가 작은 경우에는 테스트 커버리지를 높이고 관리 비용을 낮추기 위해 필요한 도구만 사용하는 것이 일반적일 것입니다. 그렇지만 팀 동료들의 테스트 도구에 대한 선호도를 고려하여 다양한 테스트 도구를 사용하기로 하였고, 테스트 커버리지를 엄청 높게 생각하지 않았기 때문에 관리가 가능할 것이라고 생각합니다.

스타일링

• CSS in JS vs CSS in CSS
  • styled-component ✅
  • emotion ui

상태(api, 전역상태)

전역 정보가 무엇이 있을지? → 유저 정보 등

상태 관리 라이브러리를 사용하지 않고 Context만으로 충분한지?

상태관리해야 할 것들이 response 데이터가 많은지?

리렌더링 등 성능 최적화를 고려할 것인지?

• Context api
• recoil ✅ (전역 상태 관리)
• jotai
• redux
• react-query (서버 상태 관리) ✅

비동기 통신

• ajax
• fetch ✅
• axios

Typescript

테스트 도구

테스트의 종류

• E2E (Cypress)

  • 페이지 기능 완성 단위로 작성 후 테스트
  • 예: 카카오 프렌즈샵에서 상품을 구매하는 경우
  1. 고객이 카카오 로그인
  2. 상품을 선택하여 장바구니에 추가
  3. 상품 구매
  4. 결제 방식 선택
  5. 구매 완료
  6. 구매 영수증을 고객 메일로 전송

• Integration (Jest, Testing Library )✅

  • 예: 카카오 프렌즈샵에서 상품을 구매하는 경우, 통합 테스트는 구매시 고객의 잔액, 재고 업데이트, 영수증 생성시 다른 구성 요소 간의 상호 작용이 잘 되어 구매가 완료되는지 확인한다.

• Unit (Jasmine, Jest, Karma, Mocha)✅

  • 예: 카카오 프렌즈샵에서 상품을 구매하는 경우, 단위 테스트는 구매 기능을 테스트할 때 고객의 잔액에서 상품의 금액 만큼 출금하는지, 상품의 재고를 업데이트 하는지, 영수증을 잘 생성하는지 각각 확인한다

선택한 테스트

• storybook: 컴포넌트 주도 개발을 위해 선택함

-react-test-library: react hook을 테스트하기 위해 선택함

서스펜스/에러 바운더리

• 직접 코드 작성해서 사용하기 ✅

eslint

• react관련 룰(훅은 use…로 시작해야한다거나) 설정
• import 모듈 순서
• eslint.rc 파일

prettier

• prettier.rc 파일
  • 한줄 글자수 제한 80자

절대경로

• 하기로 하자.