Portfolio

🔍 배경 및 궁금증

아니... 갑자기 에러가 뜬다.

계속 콘솔로 원인을 탐색한 결과, 어떤 짓을 해도 언마운트가 먼저 실행되는 괴상한 현상을 발견했다.

4시간 째 에러를 수정하면서 느낀 결과는 로직 상에서 큰 문제는 없어보였다.

그렇다면 어디에서 문제였을까? 나는 하나하나 모든 수상한 컴포넌트 로직들을 다 뜯어보았다.

기존 코드에서 Modal을 Render 메서드로 마운트했던 것이 문제였다.

아니... 큰 문제가 없어 보였는데, 왜 이것이 문제일까?

그것은 바로, Render와 createPortal의 큰 차이점 때문이었다.

둘은 흡사 어떤 컴포넌트의 하위에서 렌더링을 해준다는 공통점이 있었지만,

💡

Render은 부모 컴포넌트와의 라이프사이클을 공유하지 않는 반면, createPortal은 부모 컴포넌트와의 라이프사이클을 공유했다.

만약에 Render을 했다고 해보자.

그렇다면 부모 컴포넌트에서의 라이프사이클, 즉 update부터 시작해서 unmount 등등이 만약 발생했다면 이를 같이 한다고 보장해줄 수 없다.

💡

왜냐? 이 친구는 깐부가 아니라 남의 집 자식이다. 따라서 독립적으로 살아간다는 것이다.

하지만 createPortal을 했다면 어떨까?

💡

이 친구는 그래도 자취하러 이사 간 우리 집 자식이다. 그렇기 때문에 부모가 무슨 일이 있었다면 희노애락을 같이 해주는 자식인 것이다.

따라서 라이프사이클이 부모에게 종속된 상태이기 때문에, 잘 업데이트를 해주는 것이다.

같은 app의 하위 컴포넌트로 렌더링이 되었음에도 불구하고,

결국, 4시간을 통째로 날리면서 해결할 수 있었다.

아니다.

이런 악조건 속에서도, cleanup을 제대로 하라는 메시지 경고가 뜨지 않았다.

즉 더 리액트에 맞는 최적화된 로직을 만들어낸 것이다.

또한, 앞으로 발생할 수 있었던 render관련 라이프사이클 이상 현상을 초기에 해결할 수 있었다.

또한 팀원들과 해당 이슈를 공유함으로써, render 메서드 사용을 지양할 수 있었다.

이러한 side effect를 고려했을 때, 이 정도의 투자는 꽤나 효율적이었고, 충분했다.

앞으로도 꾸준히 이런 좋은 로직들을 만들기 위해 노력할 것이다!!!

💡

4시간의 결과: 이제, render은 함부로 사용 금물이다!