mount

리액트에서 마운트(Mount)는 DOM 객체가 생성되고 브라우저에 나타나는 것을 의미한다.

말 그대로 브라우저에 '나타나는' 것이기 때문에 유저가 직관적으로 확인할 수 있는 부분이기도 하다.

리액트는 크게 컴포넌트가 마운트되고, 업데이트되고, 언마운트가 되는 흐름을 가지고 있다.

(상세 페이지 컴포넌트 언마운트 -> 주문/결제 컴포넌트 마운트 -> 주문/결제컴포넌트 언마운트 -> 메인페이지 컴포넌트 마운트 )

팀 프로젝트에서 생긴 일

문제의 시작

내가 맡았던 파트 중
주문/결제 기능에 대한 우리의 플로우는 간단하게 설명하자면 아래와 같다.

상세페이지 : 데이터[유저가 선택한 상품 정보] 서버로 POST ->
서버 : AccessToken의 [UserData], [선택된 상품 정보]를 종합하는 임시 데이터 생성->
주문 페이지 : 종합된 임시 데이터를 받아 유저에게 표시, 추가해야하는 데이터, 필요없는 데이터 등을 종합하여 서버로 POST

우리가 생각해도 최적의 플로우는 아니었지만 (임시데이터 등),
제한 시간 안에 완성본을 만들려면 어쩔수 없는 선택이었다. (...정말?)

여기에서 임시데이터가 우리의 발목을 잡았는데
(이야기가 길어져서 죄송합니다..)

위 플로우는 유저가 결제페이지에서 무조건 결제를 진행해야한다는 전제조건이 붙기 때문이다.

만약 유저가 결제를 진행하지 않았을경우, 해당 임시 데이터는 쓸모없는 데이터가 되어 버리고, 서버의 공간만 낭비하게 될 것이었다.

그래서 우리는 유저가 결제를 진행하지 않고 결제 페이지를 나갈때, 해당 임시 데이터를 삭제할 필요성이 있었고,

여러 상황적 조건속에서 내가 그 부분을 해결해보겠다고 했다.
(결국에 해결 못했다. 압도적 ㅈㅅ...)

componentWillUnmount

먼저 내가 생각한 방법은 componentWillUnmount() 메소드를 사용하는 것이었다.
(지금와서 생각해도 다른 별다른 방법이 생각나지 않는다)

임시데이터 가 삭제되야할 조건은 유저가 주문/결제페이지를 나갈때 였음으로 주문/결제 컴포넌트가 unmount될때 해당 로직을 실행한다면 문제가 해결될 수 있을것이라 생각했고,
당연하게도 내 생각되로 되지 않았다. (언제나처럼)

내가 원했던 상황과는 다르게 로직은 조건부로 실행이 되었고,
componentWillUnmount()가 어디까지 담당하는건지에 대한 궁금증이 생기게 되었다.

리액트 라이프사이클이 동작하는 경우

해당 테스트를 위해 componentWillUnmount()함수가 실행될때
it works! 라는 알람을 띄우게 했고,

노란색 테두리의 주문/결제 컴포넌트에 아래와 같은 함수를 추가하였다.

componentWillUnmount() {
  alert('it works!');
}

컴포넌트 내부 인터렉션

컴포넌트 내부에서의 인터렉션에 의해서 실행되는 라이프사이클 메소드는 당연히 잘 작동한다.

브라우저 뒤로가기 버튼

뒤로가기 버튼에서 componentWillUnmount()는 총 2가지 방법에서 다른 방식으로 작동한다.

1. 정상적인 인터렉션 흐름 중 뒤로가기 버튼을 눌렀을때
   
   -> componentWillUnmount() 정상적으로 실행

2. 비정상적인 인터렉션 흐름 중 뒤로가기 버튼을 눌렀을때
   

-> componentWillUnmount() 실행 안됨

새로고침

componentWillUnmount() 실행 안됨

브라우저 종료

componentWillUnmount() 실행 안됨

결론

위 문제들에 대해 원인을 찾아보려했지만, 생각보다 글이 길어질것 같아 간단한 시리즈물로 포스팅하기로 결정했다.
(당장 할게 너무많다 ㅜㅜ)

몇가지 찾은 키워드는 리액트의 라이프사이클과 브라우저의 라이프사이클을 동일시 생각하면 안된다는 것이다.

가령 리액트는 Component의 Mount / Update / Unmount 등의 라이프 사이클이 존재하지만,

브라우저에는 DOMContentLoaded / Load / BeforeUnload,Unload 와 같은 주요 라이프 사이클이 존재한다

즉 우리가 완벽한 페이지를 만들고 싶다면 브라우저와 리액트 양쪽단의 플로우와 라이프사이클을 잘 이해하는게 중요하다고 깨달았다.
(한동안 리액트 리액트 하다보니 사고가 너무 리액트에만 갇혀있지 않았나 돌이켜 본 계기가 되었다.)

• 뒤로가기의 경우의 수로 보건데, 리액트의 기능은 어느정도 브라우저단(window객체)에도 영향을 주는게 아닐까 란 생각을 해보았다. 최소한 리액트에서의 hitory와 브라우저에서의 history는 특정 상황에서 어느정도 연관성을 지니고 있는게 아닐까란 내 의견이다.

배우면서 궁금한점은 갈수록 쌓여가고, 해당 궁금증을 풀 시간은 지금의 나에겐 없다.

Alice's Rabbit Hole에 빠지는 것은 위험하다고 늘 조언받지만, 
나는 전문가가 되고싶어서 개발자의 길을 선택한 것이다. 
그리고 나는 전문가는 자신의 행동에 명확한 이유가 있는 사람이라고 생각한다.
그리고 rabbit hole은 전문가가 되고 싶은 나에게 행동할 수 있는 자신감을 준다.

하지만 지금은 개인적인 만족감을 뒤로하고 
주어진 환경 내에서 최선을 다하는 것이 내가 할 일이리라 생각하며,
또 한번 스스로를 타이르고, 또 한번 자존감을 추스린다.