[우아한테크코스 FE 5기] 레벨2 쇼핑주문(협업) 미션 회고

Chex·2023년 6월 15일

우테코

우아한테크코스

목록 보기

13/19

쇼핑주문 미션 실행화면

이번 미션은 백엔드 크루들과 협업하여 API 명세를 작성하고 재화 관련 요소를 포함한 주문기능을 구현하는 것을 목표로 진행했다.

우리 팀에서 선택한 재화 요소는 쿠폰이다. 쿠폰 명세는 아래와 같다. (+ API ErrorCode 명세)

🎟 쿠폰 명세 🎟 

쿠폰 종류
- 5%: 가입 시 쿠폰발급
- 10%: 삼백만원 이상 구매 시 쿠폰발급
- 30%: 천만원 이상 구매 시 쿠폰발급
- 50%: 이천만원 이상 구매 시 쿠폰발급
- 90%: 오천만원 이상 구매 시 쿠폰발급

쿠폰 사용 제한
- 상품 구매 가격에 따른 쿠폰 지급
- 유효기간 O(유효한 쿠폰만 서버에서 전송)
- 최소 주문금액 이상 구매 시 사용 가능
- 주문당 쿠폰 1개 사용 가능

📝 협업소감

실제로 백엔드 크루들과 만나 협업을 하는 것은 이번이 처음이었는데, 굉장히 인상깊고 재밌는 경험이었다!
기능 구현 전, 시나리오에 대해 서로 이야기하는 것도 재미있었고
유쾌하고 친절한 백엔드 크루들 덕분에 API명세를 정하는 것도 순조롭게 진행할 수 있었다.
특히 에러상황에 대한 커스텀 상태코드를 정하면서 막막했던 에러처리에 대한 방향성이 생겼고 동기부여를 얻을 수 있었다!

한 가지 사소한 문제(?)가 있었던 점은 쿠폰을 적용하는 대상에 대한 것이었는데,
나는 배송비를 합한 금액에 쿠폰을 적용했고 백엔드 로직에서는 배송비를 제외한 금액에 쿠폰을 적용했기 때문에 5002에러(최종 가격과 넘어온 가격이 다른 경우)를 만났었다. 이것을 계기로 이런 작은 부분도 빼놓지 말고 협의를 해야겠다고 생각했다.

📝 MSW(Mock Service Worker)

MSW로 백엔드 API를 모킹하여 이렇게 저렇게 넘어올 것이다~하고 진행했는데 이번 미션에서 MSW의 유용함을 정말 많이 느꼈다. 백엔드 API가 늦어졌지만 그것과 상관없이 내가 모킹한 API로 미션을 진행할 수 있었기 때문이다. 또한 https에 대한 대응이 안되어있기 때문에 백엔드 서버로는 배포 페이지에서 기능 동작이 안되지만 MSW용을 따로 만들어 배포 페이지에서 기능을 테스트할 수 있도록 할 수 있었다.

백엔드 팀원들과 API 명세만 미리 잘 협의해두면 앞으로도 MSW를 통해서 독립적인 개발을 할 수 있을 것 같다. 아주 굿굿..

📝 상태관리

기존 로직에서는 장바구니 목록뿐만 아니라 상품목록도 전역으로 상태관리를 했었다.
하지만 상품목록이나 주문목록 같은 경우엔 모든 컴포넌트가 알 필요가 없다고 생각해서 로컬상태로 관리하도록 수정했다. 어떤 기준을 갖고 로컬과 전역상태를 나누어야할지 고민을 해보았는데 일단 2개 이상의 페이지에서 사용하는 상태는 전역으로 관리하기로 정했다.

📝 비동기 데이터 요청

기존 로직에서는 장바구니 목록을 불러오는 로직도 recoil의 selector를 이용했으나 이전 값을 기반으로 값을 캐싱하는 selector의 특성상
장바구니 목록의 경우 사용자의 조작에 따라 매번 다른 데이터를 받아올 수 있기 때문에 selector에서 해당 로직을 분리했다. 이전 장바구니 미션 코멘트 참고

모든 API 요청 로직은 커스텀 훅으로 분리했다. (e.g. 장바구니 수량 조절 시 patch 요청을 보내도록 요청)

커스텀 훅 - APIHandler - fetchAPI로 레이어를 분리해보았다!

APIHandler: get, post, path, delete를 담은 API 추상화 모듈
fetchAPI: fetch함수를 통해 요청을 하고 그에 대한 응답을 ResponseResult타입 객체로 묶어서 반환하는 함수

export interface ResponseResult<T> {
  result: T | undefined;
  statusCode: number;
  location?: string;
  errorCode?: number;
  errorMessage?: string;
}

📝 에러처리

에러처리를 어떻게 해야할지 고민을 해보다가 더 작은 컴포넌트로 쪼갠 후 ErrorBoundary를 이용해서 에러처리를 하도록 했다.
장바구니 페이지에서 통으로 ErrorBoundary를 적용하면 전체 화면이 날아가기 때문에 TotalPayment 등 에러가 날 것 같은 경계 부분에 ErrorBoundary를 적용했다.

👇 그리고 이것이 ErrorBoundary의 가장 큰 장점이라고 느꼈다. 에러가 났을 때 앱이 통째로 죽는 것이 아니라 경계를 나누어줄 수 있다는 점이 아주 편리했다👍
장바구니 에러바운더리