마켓컬리 클론코딩 트러블 슈팅 겸 회고

✔️ [FE] 리액트 쿼리의 능동적 활용

리액트 - 쿼리 이슈

메인화면에서 카테고리를 누를 때 마다 GET을 해오는 과정이 능동적으로 진행되 질 않아 상당한 고생을 했다. 메인화면에 처음 들어올 때 전체 리스트를 받아오는 GET하고 부분항목을 받아오는 GET의 구 조가 달라 문제 발생

해결

전체용 GET을 받아오고 그 다음 카테고리용 GET은 enabled를 false로 체크 , 이후 버튼을 누 를 때 비로소 발동하도록 하여 useQuery의 발동 을 원하는 때에 발동시키도록 조절했다. 화면에 랜더링되는 ITEM들은 useState로 일괄 관리하였기에 처음엔 전체GET을 저장, 이후엔 리 스트 리셋 후 부분GET을 저장시키는 방식으로 화 면 새로고침을 하지 않고 진행했다.

회고

코드를 다시 살펴본 결과, 실전 프로젝트 Navis에서 해결한 종류의 문제였다. useQuery를 한 페이지에서 다수 사용할 때 사용한 문제였는데, 지금와서 보면 카테고리용 useQuery가 분리되어 있는데, 그냥 한 API에 카테고리를 all로 가져와서 출력하는 방식을 채택하면 하나의 useQuery로 해결할 수 있지 않았을까 하는 아쉬움이 있다.

---

 

✔️ [FE] 꼬여서 넘어오는 데이터

꼬여서 넘어오는 장바구니 데이터

장바구니 페이지에서, 냉장, 냉동, 상온 식품을 보관방식 별로 별도 리스트로 받아 문제 발생했다. 

(데이터)교통정리

하나하나 분리된 리스트의 ITEM들 을 다시 하나로 관리하기 위해 벡엔드에 API 구조의 변경을 요청하였으며 프론트엔드에서는 리덕스 툴킷을 활용해 넘어오는 데이터를 관리하였다.

회고

코드의 흐름을 천천히 따라가보니, 데이터가 변경될 때 마다 For문을 3번씩 돌리면서 상온, 냉장, 냉동별 장박바구니 데이터를 긁어오고 분배하는 상황을 파악했다. 만약 다시 만든다면 우선 하나의 배열로 장바구니 데이터를 받아오고, For문을 한 번만 돌리면서 내부에서 Switch로 3종류 카테고리에 분배하는 방식을 사용할 것 같다.