[TIL/React] 2023/10/25
상세 페이지 ✍️ 상세 페이지에서 '바로구매' 버튼을 클릭하면 144번 라인의 handleDirectClick 함수가 실행된다. dispatch를 통해 getCartData라는 액션 함수로, 상세 페이지 상의 상품 정보를 전달한다. category와 count가 추가
상세 페이지 ✍️

상세 페이지에서 '바로구매' 버튼을 클릭하면 144번 라인의 handleDirectClick 함수가 실행된다. dispatch를 통해 getCartData라는 액션 함수로, 상세 페이지 상의 상품 정보를 전달한다. category와 count가 추가된 정보가 전달되는 것이다. 가령 달걀을 3개로 설정한 뒤 바로구매를 클릭하면 count가 3이 된 상품 정보가 전달된다.

slice에서는 부차적인 과정을 거친 뒤, cartProduct라는 빈 배열에 해당 정보(=객체)를 추가한다.
'상세 페이지 Counter'의 역할은 여기까지가 끝이다. 개수를 증가시키고 증가된 상태를 반영해서 배열에 추가하는 것이 전부이다.
장바구니 페이지 ✍️

장바구니 페이지는 기본적으로 위 cartAddedProduct에 대한 mapping을 수행하는 페이지다.

mapping의 과정에서 별도의 Counter를 보여주게 된다. handle 함수에 모두 item을 전달하고 있는데, 여기서의 item은 cartAddedProduct의 개별 요소, 즉 추가된 상품 하나하나를 의미한다. 앞에서 든 예시로 비유하면 (달걀 +3)이 item 중 하나일 것이다.

dispatch를 통해 개별적인 상품 정보를 '일단' 각각의 액션 함수로 전달한다. 증가든 감소든 클릭하면 일단 내가 선택한 상품 정보가 전달되는 것이다.

(달걀 +3)이 increaseCartData에 action.payload로 전달되었다고 가정하자. 사용자가 클릭한 +로부터 들어온 정보가, 이미 추가된 상품의 정보와 일치하는지를 findIndex method를 통해 검증한다. 일치하는 index가 있다면, 해당 index 객체의 count에 1을 추가한다.
decrease는 increase 로직과 동일하다. 다만 1을 감소시킬 뿐이다.


결과적으로 item.count를 통해, 실시간으로 변경된 개별 객체의 count를 보여줄 수 있게 된다.
회고 ✍️
정확히 6개월 전에, '상태관리'라는 단어 자체를 처음 알게 되고 학습하면서 괴로워했던 것이 기억난다. 오늘 정리한 내용을 구현하는 과정에서 비슷한 감정이 들었다. 그 때 만큼은 아니었지만.
잘 하려고, 열심히 하려고 해서 그런 감정이 스친 것이라고 생각한다. 한 번의 성취 내지는 구현까지는 수많은 삽질이 필요하다. 사람마다 다르겠지만, 그 양은 어쨌든 정해져 있다고 믿는다. 같은 내용을 구현하기까지 누구는 10번 실패해야하고 다른 누구는 100번 실패해야 한다. 어쩔 수 없는 할당량 같은 것이다.
잘 하려고, 열심히 하려고 하는 마음은 사실 결과와 크게 상관 없다. 그저 다양한 방향으로 많이 고민하면서 수많은 reject을 지워나가면 결국 성공은 주어진다. 운 좋게 얻어진 것처럼.
주니어 개발자를 채용할 때 성장 가능성을 가장 높게 본다고들 하던데, 내 생각에 '성장 가능성'은 'reject을 사랑하는 태도'와 동일한 말인 것 같다. 결과는 일시적인데, 결과만 좋아하면 개발을 좋아할 수가 없다. 긴 시간이 실패의 점으로 구성되기에, 사실은 실패(=결과로 이어지지 못한 시도)를 사랑해야 한다.
요즘 '결과로 이어지지 못한 시도' 자체가 꽤 매력적으로 느껴진다. 아무튼 좋다. 열심히 하지 말고 잘 하지 말고, 많이 할 생각만 하자!
More to read
프론트엔드와 백엔드 사이
HTTP 상태 코드는 프론트엔드에서 백엔드로 보냈던 요청의 수행 결과를 의미하는 일종의 약속이며, API를 구성하는 핵심 요소 중 하나입니다. 상태 코드와 관련하여, 백엔드는 잘 모르는 프론트엔드의 슬픈 사정이 있습니다.아래는 요청이 실패했음에도, 백엔드에서 상태 코드
JWT토큰 관리 방식 톺아보기
0. 들어가며 🎯 서비스에 접근하려는 사용자가 누구인지 확인하는 과정을 사용자 인증이라고 합니다. 인증된 사용자에게 주어진 권한을 확인하는 작업은 인가라고 부릅니다. 이번 글에서는 인가는 다루지 않습니다. 사용자 인증에는 많은 방식이 있지만, 오늘은 세션 인증 방
A2AA2A / MCP 멀티 에이전트 오케스트레이션
0. 들어가며 ✍️ Google for Developers에, 레스토랑 공급망 시나리오로 엮은 6대 프로토콜(MCP, A2A, UCP, AP2, A2UI, AG-UI)에 대한 가이드가 게시된 이후, MCP와 A2A부터 구현해 보는 것이 좋을 것 같다는 생각이 들었습니