상태, State는 데이터를 담을 수 있는 React의 내장 객체 중 하나입니다. 상태에 담긴 값은 사용자의 액션이나 네트워크 등 개발자의 의도에 따라 값이 변경될 수 있는데, 이 때 상태값을 사용하고 있는 컴포넌트는 변경된 값을 반영해 다시 렌더링됩니다. 즉, 상태는 컴포넌트에 영향을 주는 동적인 데이터입니다.
친구의 인스타그램을 구독하려 한다고 가정해봅시다. 프로필 화면에 들어가면 “팔로우” 버튼이 보이는데, 이 것을 누르면 버튼의 텍스트는 **“팔로잉”**로 변경되며 친구의 팔로워 숫자가 1 증가하게 됩니다. 이 경우에는 “사용자를 팔로우”하는 액션으로서 “내가 이 사용자를 팔로우하고 있는가”와 “이 사용자는 몇 명의 팔로워를 가지고 있는가”에 관한 상태 값을 변경한 것입니다.
위의 예시와 같이, 상태는 시간이 흐르며 실시간으로 변화합니다. “팔로워 수” 상태가 증가하거나 감소하기도 하고, 비동기 요청에 대한 응답이 돌아왔는지에 따라 “로딩중” 상태가 true 혹은 false로 변경되기도 합니다. 따라서 프론트엔드 개발자는 1)상태를 UI/UX에 맞게 정제해 사용자에게 보여주고 2)상호작용에 의한 상태의 변경을 다루어야 하는데, 이 것을 상태 관리라고 합니다.
프로젝트의 규모가 커지게 되면 상태가 점점 많아지고 하나의 상태를 공유하는 컴포넌트가 늘어나 구조가 점점 복잡해집니다. 덕분에 상태가 언제, 어디서, 어떻게, 왜 변화했는지 추적할 수 없는 상황까지 도달하게 되는데, 이런 상황을 방지하기 위해 상태를 어디에 저장할 것인지, 네트워크 요청이나 응답에 따라 상태를 어떻게 변경할 것인지 등을 고려해 상태를 잘 설계하는 것이 중요합니다.
상태를 전역적으로 관리해야 할 때가 있다
언제 어떤 상황에서 전역 상태관리가 필요할까요?
React는 UI 컴포넌트를 재사용 가능한 단위로 잘게 쪼개고, 그것을 합성하는 아키텍처를 권장합니다. 그런 React의 이념을 충실히 따르다 보면 컴포넌트 트리의 깊이가 점점 커지게 되는데, 때문에 하나의 상태를 다양한 컴포넌트가 참조하는 상황에서는 상위의 컴포넌트에서 상태를 만들고, 값이나 setter를 하위 컴포넌트의 prop으로 전달해주어야 합니다. 이 때 props를 오로지 하위 컴포넌트로 전달할 뿐 자신은 상태 props를 필요로하지 않는 컴포넌트가 생기게 되는데, 이것을 Prop Drilling 현상이라고 합니다.