React Life Cycle

클래스형 컴포넌트의 구조

앞서 살펴본 리액트의 클래스 컴포넌트의 구조를 정리해보면 아래와 같다.

클래스는 React.Component를 상속하고 constructor를 비롯한 LifeCycle관련 함수 정의하고 eventHandler들을 정의한후 반환할 JSX태그들을 렌더하기.

 

이렇게 모양은 생겼지만 언제 생겨나서 언제 수정되고 인터렉션에 따라 사라지기까지 하는 컴포넌트의 생애에 대해서 잘 알아야 계속 변하는 컴포넌트들을 제대로 활용할 수 있으므로 알아보자.  

 

컴포넌트의 Life Cycle

간단히 말하자면 위 그림과 같다. 크게 3단계로 생성될 때, 업데이트 할 때,제거할 때로 나뉘어 그때마다 자동으로 호출할 수 있는 함수가 있는 것이다.

자세히 말하자면 각 단계에서 왼쪽과 같이 호출하는 함수가 더 많다. shouldComponentUpdate에서 업데이트 여부에 따라 불필요한 render를 하지 않기도 하고 하나 우선은 위의 그림에 따라 컴포넌트의 생애 주기를 살펴보고자한다. 

 먼저 하나의 컴포넌트에 대해서만 생각해보면 생성될때 constructor()를 호출하고 그 다음 render를 호출한다. 마지막으로 componentDidMount가 정의되어 있다면 이것이 호출된다.

 

 컴포넌트가 업데이트된다고 간주하는 경우는 3가지 경우이다.새로운 props가 들어올 때,setState()를 만났을 때, forceUpdate()를 만났을 때. 이 중 마지막의 경우는 사용이 추천되지 않는다.

 마지막으로 컴포넌트의 제거이다. 제거된 후에는 컴포넌트를 사용할 수 없기에 이름도 componentWillUnmout()이다.이 함수를 통해 컴포넌트 기능을 멈춰야만 제대로 제거되었다고 할 수 있다.

 

즉,크게 4가지 함수-Constructor, ComponentDidMount, ComponentDidUpdate, ComponentWillUnmount에 의해 생성,업데이트,제거의 생애주기가 이루어진다고 할 수 있다. (생성은 렌더와 마운트, 업데이트는 리렌더와 업데이트로 세분화되지만) 그러나 컴포넌트는 하나로만 이루어진것이 아니다. 부모 컴포넌트가 있고 그 안에 자식 컴포넌트가 있는 경우가 많다. 이전의 예제들도 App컴포넌트 안에 WorldClock컴포넌트가 있다던지 한 예제였다. 이렇게 부모-자식 관계를 갖는 컴포넌트들은 어떻게 맞물려 LifeCycle을 갖게 될까?>

 

부모-자식관계 컴포넌트들의 생애주기

사실 React에서 컴포넌트들은 복잡한 부모-자식관계를 가지고 있으므로 생성할때, 각각 업데에트 될 때,삭제 될 때 순서를 보자. WorldClock컴포넌트 만들었던 예제에서 여러 함수들에 console.log()를 통해 순서를 살펴봤당(여기서 부모는 App컴포넌트, 자식은 그안에 있던 WorldClock컴포넌트)

 

1.생성(자식 컴포넌트 +Mount)

옆의 App컴포넌트같이 constructor,render,componentDidMount함수에 상태를 알리는 console출력들을 자식 컴포넌트에도 똑같이 작성해주었다. 뒤에 2-4에서도 같은 방식으로 추가로 componentDidUpdate()와 componentWillUnmount()에도 작성해 출력 순서를 보는 방법을 이용했다~!

 

그랬더니 아래와 같은 결과가 나왔다.

부모의 생성과 렌더링->자식의 생성과 렌더링+마운트->부모 마운트

 

*이벤트가 들어오는 부분은 event.target.value *

 

 

 

 

2.자식 업데이트(자식 컴포넌트+Mount+자식만 업데이트)

WorldClock컴포넌트에서 setInterver로 this.setState()를 호출해 시간을 계속 바꾸는 로직이 있으므로 componentDidUpdate()가 정해진 시간마다 호출된다. WorldClock컴포넌트에 업데이트 함수에 콘솔출력을 작성하고 본 결과는 아래와 같았다.

   부모의 생성과 렌더링->자식의 생성과 렌더링+마운트->부모 마운트

    ->자식의 렌더링->자식의 업데이트

 

 

 

3.자식 컴포넌트+부모의 업데이트

이번엔 부모 컴포넌트인 App에 textarea에 글을 적어 componentDidUpdate()가 호출되도록 해보았다.

   부모의 생성과 렌더링->자식의 생성과 렌더링+마운트->부모 마운트

      (->자식의 렌더링->자식의 업데이트)

        ->부모의 렌더링->부모의 업데이트->자식의 렌더링과 업데이트(이를 반복하게 된다)

 

4.자식 컴포넌트+부모의 업데이트+최적화

 3의 경우에서 자식컴포넌트는 변화가 일어나지 않았는데도 부모의 업데이트로 인해 자식도 다시 렌더링과 업데이트가 되어버렸다. 이를 피하기 위해 자식 컴포넌트를 만들 때 PureComponent-라이프사이클- 나 ShouldComponentUpdate-클래스-를 상속하도록 만들 수 있다.

*둘의 차이

shouldComponentUpdate는 모든 업데이트마다의 코드를 직접 짤 수 있다. 
PureComponent는 미리 작성된거로 가져다 쓰면 되서 편하다

 

왼쪽은 React.PureComponent를 상속해 만든 자식 컴포넌트이다. 그럼 결과가 아래처럼 나오게 된다.

부모의 생성과 렌더링->자식의 생성과 렌더링+마운트->부모 마운트

      (->자식의 렌더링->자식의 업데이트)

          ->부모의 렌더링->부모의 업데이트(이 둘 만 반복하게 된다)

이렇게 자식 컴포넌트가 부모 컴포넌트의 업데이트에 따라 업데이트가 되는지 여부를 검사하고 시행할 수 있다.

 

 

*componentDidMount에서 this.setState()를 사용하고 있다*

 

 

 

5.자식 컴포넌트 UnMount

부모인 App컴포넌트에 오른쪽과 같이 손가락 튕기기 버튼을 두어 누르면 WorldClock컴포넌트가 모두 보이지 않도록 만들어보았다.

 

App의 constructor() state에 show를 true로 선언하고

손가락 튕기기 버튼이 눌릴때마다 show가 false와 true를 이전상태와 비교해 바뀌도록 하였다.

 

*prevState가 이전 state의 정보를 가지고 있다*

 

또 show가 true일때만 자식 컴포넌트가 보이도록 하였다.

그럼 손가락 튕기기 버튼을 처음 눌렀을 때 자식 컴포넌트들이 사라지면서 componentWillUnmount()가 호출되겠지.아래처럼.

그러나 Warnint이 떴다.왜냐면 Unmount됐음에도 자식컴포넌트의 state인 hour와 minute이 계속해서 변하고 있기 때문에 메모리 문제가 생길 수 있다고 알려주는 것이다. 따라서 WorldClock컴포넌트의 componentWillUnmout()에  옆과 같이 clearInterval()을 써야 메모리 낭비를 막을 수 있다.

 

 

 

LifeCycle 함수의 역할 정리

 

Constructor()에서는 state를 선언한다. setState를 할 수 없다.

 

 

 

 

 

 

 

 

 

ComponentDidMount에서는 필요한 데이터를 요청하고 각종 비동기를 요청한다. 최초의 setState를 한다.

 

 

 

 

 

 

ComponentDidUpdate에서는 업데이트 이후 수정이 필요한 것을 작성한다. 그런데 setState()를 사용할때 꼭 조건분기를 두어야한다.

 

 

 

 

 

 

 

ComponentWillUnmout()에서는 컴포넌트가 없어지면서 같이 사라져야하는 등의 요청을 한다. setState를 직접 작성하지 않고 다른 함수를 호출함으로써 가능하다.