state라는 개념이 도입되자, 팀의 논의는 자연스럽게 그 state의 생애 첫 순간, 즉 초기화 과정으로 이어졌다. 조던 워크는 getInitialState 메서드의 역할을 명확히 하는 것이 매우 중요하다고 강조했다.
“getInitialState는 컴포넌트의 ‘창세기’와 같습니다. 이 메서드가 호출되는 바로 그 순간, 컴포넌트는 비로소 자신만의 첫 번째 기억, 즉 state를 가지게 됩니다.”
그는 이 메서드가 가지는 몇 가지 중요한 규칙과 의미를 설명했다.
규칙 1: 오직 생성 시에만 단 한 번 호출된다.
getInitialState는 컴포넌트의 설계도(React.createClass로 만든 클래스)로부터 실제 인스턴스가 만들어지는 과정에서, render가 호출되기 직전에 딱 한 번만 실행된다. 한번 생성된 컴포넌트가 화면에 계속 떠 있는 동안에는, 부모로부터 받는 props가 아무리 바뀌어도 getInitialState는 다시는 호출되지 않는다.
이 규칙은 state가 컴포넌트의 ‘내부’ 소유물임을 명확히 했다. state의 시작은 외부(props)로부터 영감을 받을 수는 있지만, 일단 태어난 후에는 오롯이 컴포넌트 자신의 책임 아래 놓이게 되는 것이다.
규칙 2: 부모로부터 받은 props를 사용하여 초기 상태를 설정할 수 있다.
<LikeButton> 예제에서처럼, getInitialState 메서드 내부에서는 this.props에 접근할 수 있다. 이는 컴포넌트의 초기 상태가 외부에서 전달된 값에 따라 동적으로 결정될 수 있게 해주는 강력한 기능이었다.
// LikeButton.js
getInitialState: function() {
// 부모가 내려준 props를 보고, 자신의 첫 기억을 결정한다.
return { isLiked: this.props.initialIsLiked };
}
톰이 이 부분을 보며 질문했다.
“이건 props를 state에 복사하는 것처럼 보이는데, 데이터가 중복되는 건 아닌가요?”
“좋은 지적입니다.” 조던이 대답했다. “하지만 이건 단순한 복사가 아닙니다. ‘씨앗(seed)’을 심는 과정에 가깝습니다. 부모는 자식에게 ‘이 씨앗(props)을 줄 테니, 네 밭(state)에 심어서 앞으로 네가 직접 키워라’고 말하는 거죠. 씨앗을 심은 후에는, 그 싹이 자라고 열매를 맺는 모든 과정은 전적으로 자식의 책임입니다. 부모는 더 이상 그 밭에 간섭하지 않아요.”
이 비유는 props와 state의 관계를 명확히 했다. props는 state의 시작점이 될 수는 있지만, 그 둘은 서로 다른 생명주기를 가진 별개의 존재였다.
규칙 3: 상태 없는 컴포넌트는 이 메서드를 가질 필요가 없다.
만약 어떤 컴포넌트가 내부적으로 변하는 상태를 가질 필요가 없다면, getInitialState 메서드를 아예 정의하지 않으면 된다. 이 경우, 해당 컴포넌트는 this.state 자체가 null 값을 가지게 되어, 상태가 없음을 명시적으로 나타낸다. 이는 개발자가 컴포넌트의 복잡도를 한눈에 파악할 수 있게 도와주는 중요한 단서가 되었다.
getInitialState의 역할이 명확해지면서, 리액트 컴포넌트의 탄생 과정은 더욱 정교해졌다.
- 컴포넌트 인스턴스가 생성된다.
getInitialState가 호출되어this.state가 초기화된다.render가 호출되어this.props와 갓 생성된this.state를 바탕으로 첫 번째 버추얼 DOM을 생성한다.
컴포넌트의 첫 기억이 어떻게 만들어지는지가 정의되었다. 이제 팀은 컴포넌트의 생애에서 가장 역동적인 순간, 즉 사용자의 행동이나 시간의 흐름에 따라 이 ‘기억’을 어떻게 안전하고 예측 가능하게 ‘갱신’할 것인가라는 가장 큰 숙제를 마주하게 되었다.
