상세 페이지 ✍️
상세 페이지에서 '바로구매' 버튼을 클릭하면 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을 사랑하는 태도'와 동일한 말인 것 같다. 결과는 일시적인데, 결과만 좋아하면 개발을 좋아할 수가 없다. 긴 시간이 실패의 점으로 구성되기에, 사실은 실패(=결과로 이어지지 못한 시도)를 사랑해야 한다.
요즘 '결과로 이어지지 못한 시도' 자체가 꽤 매력적으로 느껴진다. 아무튼 좋다. 열심히 하지 말고 잘 하지 말고, 많이 할 생각만 하자!
