이제 유즈 스테이트 변경의 효율성과 더불어 기존에 언급한 컴포넌트의 지역성을 고려한 대 보수공사에 대해 적어보고 필자의 마지막 느낀 점으로 마무리하겠다.

01. 유즈 스테이트의 변경점.

자! 다시~ 이제 저 영으로 난무하는 초기 값의 유즈스테이트를 보자! 필자는 저 영이 분명 문제가 있음을 지적했었다. 왜? 지금이야 물론 우리가 데이터가 많지 않기 때문에 저렇게 데이터 수 이상만 초기값을 설정해 주면 잘 된다.

하지만!

곰곰히 생각해 보자! 장기적으로 봤을 때, 우리가 데이터를 딱 정해진 수만 받을까?

NOPE

그래서 저 초기값을 굳이 만져주지 않더라도, 예측 불가능한 데이터가 백엔드 단에서 넘어온다고 해도 활용가능한 코드로 바꿔줘야 한다. 사실 그것이 리팩토링의 진정한 본질이라고 생각한다.

02. 이제 다시 시작.

이제 다시 셋넘버를 어떻게 가져오는 지에 대해 얘기해 보겠다. 본질적으로 셋넘버는 위의 유즈스테이트의 변경되는 함수다. 그런데 저것을 프로덕트 카드의 온클릭 함수의 리턴 값으로 받는 것이 이상하지 않는가?

자 결론부터 예기하자면, 저렇게 받아줘야만 했다. 왜? 아래 그림을 보자.

의아할 수도 있겠다. 유즈스테이트의 초기값이 왜 단지 영일까? 영만 쓰면 된다. 자 다시 클릭 이미지 함수 코드를 보자.

셋 넘버 안에 인덱스를 넣어줬다. 그렇다! 이제 알아채신 분들도 있을 텐데, 다시 설명을 해 드리자면, 셋넘버가 0에서 시작해서 계속 하나씩 데이터가 있다면 커질 것이므로 저렇게 설정을 해 버리면 밑에 서브이미지가 100만개가 있더라도, 그 데이터의 인덱스 값에 따라 메인 이미지가 바뀌는 환경을 구축할 수가 있다. 얼마나 효율적인 클린 코드인지. 알 수 있는 지점이었다. 현업에서 대개 클린코드 클린코드라고 왜치는 것이 이런 불순물들을 제거하기 위한 용도라는 것을 알 수 있었다.

그런데....

마냥 이것만 하면 이렇게 끝인줄 알았지만.... 사실 더 큰 문제가 생기고야 마는데...

바로 저렇게하면 기존 서브 이미지는 잘 작동을 한다.

다만, 온클릭 시 전체 리스트의 메인 이미지가 바뀌는 문제가 발생하고 말았다.

03. 처음엔 이렇게까지 대공사일 줄은... 몰랐었어...

그건 또 바로 문제를 알고보니, 다시 이 놈이 문제였다.

바로 넘버 스테이트문이 리스트 컴포넌트 안에 이미 선정이 되어있기 때문이었다. 처음에는 이게 뭐가 문제인지를 몰랐다. 하지만, 이게 리액트의 특성때문이었다.

리엑트 특성상 부모 컴포넌트의 프롭스와 스테이트에 따라 자식 컴포넌트는 영향을 받고, 또한 자식 컴포넌트의 영향이 부모 전체로 가기 때문에 문제가 발생했다. 재준님이 일전에 말씀하신 지역성이 문제였다.

그래서 구조적으로 바꿔줘야만 해결될 문제라는 것을 알게 된 시점이었다.

지금까지는 이후에 대공사가 시작될 것을 미리 예고하는 예고편이다. 다음 편에서는 이 대공사의 진행과정에 대해 적어보고 느낀 후기를 다시 적어보겠다.