드디어...
대망의 대. 공. 사.... 의 서막이 올랐다.
여태까지 1, 2편은 이 과정을 위한 빌드업이라고 해도 과언이 아닐 정도다.
🤔 1. 어디부터 잘못된 공사였을까?
사실 우리가 보통 공사를 얘기하면, 부실공사하면 오래가지 못해 붕괴되는 경우를 많이 봤을 것이다.
내 코드도 마찬가지였다.
재준님은 내게 일단 유즈스테이트의 위치를 부모 컴포넌트에서 다른 컴포넌트로 옮기라고 하셨다.
그런데 도대체 의문이 들었다.
당장 저기 리스트 컴포넌트 외에 아예 자식 컴포넌트로 옮기라는 말인가? 그러면 각자 자식 컴포넌트에서 유즈 스테이트를 따로하는 건가? 그건 너무 비효율적이 아닌가?
라는 의구심과 의문이 든 시점이었다. 그러자. 그는
"아니요~ 그건 아니고 민수님 지금 컴포넌트 구조 자체가 제가 생각했을 때는 좀 잘못 되어서, 그냥 차라리 새로운 프로덕트의 부모 컴포넌트를 지정하고 거기에서 넘버의 유즈스테이트를 지정해 주는 게 좋을 것 같아요~"
🤦🏻 02. 그랬다... 나는 아직 리엑트의 상태 변경 구조와 지역성에 대해 몰랐었다.
그래서 당장 필자는 구조부터 파악했다.
🔍 1) 컴포넌트 구조의 파악.
현재의 구조는 리스트 부모 컴포넌트안에 저렇게 다 넣어져 있는 식이었다. 그런데 생각해 보니, 저렇게 되면 부모의 영향에서 자유롭지 못하고, 즉 상태 변경에도 많은 제약이 있다는 생각이 들었다.
기존 구조를 하나씩 바꿔나가기로 결정했다. 일단, 재준님의 말씀처럼 기존의 카드 컴포넌트를 묶어줄 수 있는 컴포넌트를 새로 만들기로 했다.
🛠 2) 새로운 부모 컴포넌트 생성.
그래서 필자는 새로운 부모 카드 컴포넌트로 카드 래퍼라는 명의 컴포넌트를 제작했다. 이후 그 안으로 하나씩 컴포넌트를 이주시켰다. 먼저, 2편의 문제부터 해결하기 위해 서브이미지 클릭시 전체 이미지의 상태가 바뀌는 전역 상태부터 변경해 주기로 했다. 그래서 CardWrapper라는 새로운 컴포넌트안에 기존의 유즈 스테이트를 넣어줌으로서 상태 변경에 대한 조절을 해당 컴포넌트 안에서 처리해 주도록했다.
➕ 3) 추가 작업 시작.
물론 유즈 스테이트만 바뀐다고 끝은 아니다. 여기에 추가 작업을 더 해줘야만 했다. 바로 컴포넌트 이주 작업을 해줘야만 해당, 컴포넌트들이 리스트의 영향 아래에서 바뀔 수 있었다.
다음과 같이 일단 처음에는 위치만 옮기고 프롭스만 부모에서 받아오는 식으로 바꿨다.
이런 식으로 하자, 서브이미지 클릭시 전체 이미지가 싹 다 바뀌는 문제는 해결이 되었다.
🏗 4) 보이기 시작한 다른 문제점들 1
그런데 말입니다...
좀 뭔가.... 의문과 의구심이 또 들었다. 코드가 이주는 했지만, 여기서 끝내면 안 될 것 같다는 생각이 머릿 속을 가득하게 지배하기 시작했다.
왜? x100
눈에 먼저 들어온 것은 프로덕트카드 1번 컴포넌트의 src 구조였다. 실행상에 문제는 없지만, 저기도 저렇게 굳이 다 src를 나눠 놓아야 할 필요가 없다는 생각이었다. 즉, 2번 컴포넌트와 똑같은 논리가 적용될 수 있을 거 같았다. 그리고 불 필요한 프롭스를 줄이면서 자원의 효율성 측면에도 도움이 될 것 같았다.
먼저, 프로덕트 카드도 src를 하나만 프롭스로 받고 똑같이 디테일까지만 받았다. 그리고 해당 컴포넌트 구조로 가서 맵을 돌리는 식으로 바꿔봤다.
🤕 1. 맵에 대한 철저한 고뇌.
사실 그냥 맵만 돌리면 되겠다고 생각을 해서 간단하겠네라고 생각했었다... (반성해 내 자신 ㅜㅜ...) 하지만, 그건 진짜 뭣도 모르는 소리였다.
카드 컴포넌트1은 2와는 전혀 다른 구조였다. 물론 비슷은 하지만, 그 안에서 반복되는 구조나 맵이 돌려져야할 것들이 달랐다.
🔧 1) 첫 시도 - 이중 맵
결론부터 말하자면 이중 맵을 돌릴필요가 없었고, 이로 인해 발생한 문제가 또 발생했다. 필자의 의도는 중복되는 클래스 명의 변수 처리와 이미지의 중복 처리 방지였다. 하지만, 그걸 너무 깊게 들어간 나머지, 여기서 이중 맵 처리를 해줘야만 한다고 생각했다. 하지만, 그건 오산이었다. 이러자, 결국 호버 되는 처리가 된 이미지가 하나의 이미지 풀안에 6등분 되어서 담겨서 나왔다. 원래는 3등분이 나와야 하는 것이었다.
⚙️ 2) 디버깅의 시작.
디버깅을 시작했다. 왜 이런 것일까? 브라우저에 들어오는 image.imageUrl을 콘솔을 찍어봤다. 그러자.... 답을 알았다.
바로. 이미지가 인덱스에 맞춰 3개씩 들어와야 하는데... 이게 6개를 통으로 들고오는 문제였다.
그래서 이제 문제는 알겠는데, 필자는 뭔가 제대로 하루동안 풀수가 없었다.
🙆🏻♂️ 3) 맵을 제대로 알게 되다.
이후에 같은 팀 민기님께 이런 문제를 한 번 문의해 보니,
그는 내게 굳이 이중 맵을 돌릴 필요가 있느냐고 반문했다.
그러자, 필자는 맵을 돌리는 의미에 대해 다시 설명을 드렸다. 그래서 src가 뭔지 한 번 봤으면 좋겠다는 말에, 필자는 console.log(src)를 해서 데이터가 브라우저에 어떻게 들어오는 것인지 배여드렸다.
그러자... 그는 내게 이게 src가 product.detail을 의미하는 데 여기서 맵을 돌리면 그만인데, 이중 맵이 필요한 의미를 모르겠다고 전했다.
그때... 아! 맞네... 내가 맵 돌리는 것을 너무 구조를 몰랐구나...
라는 깨달음과 함께, 맵의 구조를 바꿨다.
⛑ 4) 맵의 구조 변화.
그래서 민기님의 말씀대로, 맵을 한 번 만 돌리는 구조로 결국 변경을 했다. 그런데, 여기서 주목할 점은 src[number]다.
넘버를 준 이유를 아시겠는가? 그건 바로, 넘버를 통해 이전에 적었던 product.detail[number].image = src[number].image 가 되는 것이다. 이를 통해 필자는 이번에 기존처럼 이미지 3개가 3등분 되는 호버를 구현했다.
아 참! 아까 클래스 명 중복의 경우에는 인덱스를 부여하면서 배열 안의 인덱스를 따라가면서 바뀔 수 있도록 처리했다. 여기서 +1은 필자가 클래스 명을 1부터 지정했기 때문이다.
사실 여기서 마무리를 했어야 했지만, 그러면 어찌 필자가 대공사라고 했겠는가.... 이 이후에 다시 또 구조가 바뀐다. ㅋㅋㅋ
그에 대해서는 다음편에서 마무리해서 이번 리팩토링 시리즈를 종료하겠다. 긴 글 읽어주셔서 감사하고 다음 마무리 편도 기대해 주시라~ 😄
