상태관리의 필요성
컴포넌트에서 사용하는 상태(state)가 변경되면, 컴포넌트는 리렌더링되면서 변하는 값을 표시한다. 대부분 이 state를 다른 자식 컴포넌트에도 적용하기 위해 전달하려는 경우가 생기는데, 그 때는 props로 이 값을 내려준다.
하지만, (추가적인 작업이 없다면) 자식 컴포넌트는 이렇게 부모로부터 전달받은 state를 직접 변경할 방법이 없다.
만약 자식 컴포넌트가 부모로부터 받은 state값을 변경하고 싶다면, 부모로부터 상태값을 변경하는 함수를 props로 전달받아야 한다. (예를 들어 useState를 사용했다면, setter 함수를 넘겨주는 식.)
그런데 컴포넌트 갯수가 점점 많아지고 공유해야 하는 state가 늘어난다면 어떻게 될까?
상태값을 전달하기 위해, 또 그것을 변경하는 함수도 같이 전달하려고 부모-자식-..으로 이어지는 전달 과정을 매번 작성해야 하는 매우 비효율적인 상황이 발생한다.
내려 주는 깊이가 깊어질수록 더욱 그런 상황에 직면한다.(과도한 prop drilling).
단순히 값을 내려줄 때 불편한 것 하나로 라이브러리가 등장한 것은 아니다.
프로젝트가 커져서 컴포넌트 갯수가 많아지고 그들간에 서로 공유하는 state 값들이 많아진다면, state가 어디서 어떻게 변하는지, 그리고 이 업데이트가 어떤 컴포넌트의 어떤 작업으로 인해 발생했는지, 손쉽게 파악하기가 힘들다.
그래서 대다수 상태관리 라이브러리들이 공통적으로 채택하는 개념은
전역 상태를 관리하는 것이다.
전역 상태관리 라이브러리
상태관리 라이브러리의 종류는 다양하다. Redux, MobX, Recoil 등등 많은 도구들이 존재하고, 각 라이브러리마다 장/단점이 있다.
우리는 그 특성들을 알고 진행하는 프로젝트의 특성에 맞게 골라 쓰면 된다.
Context API
Redux
Javascript App을 위한 예측 가능한(predictable) 상태 컨테이너
Actions : 저장소로 data를 보내는 방법.
Reducer : Action을 통해 어떠한 행동을 정의하고, 그 결과 어플리케이션의 상태가 어떻게 바뀌는지는 특정하게 되는 함수.
Store : Action과 상태를 수정하는 reducer를 저장하는 단 하나의 객체
React의 Component자체는 Redux의 흐름에 타는 것이 불가능함.
-> connect 함수를 이용.
Redux는 Flux의 구현체 느낌.
Flux : 대규모 프로젝트에서 너무 복잡해지는 MVC구조의 단점을 보완하는 단방향 데이터 흐름 (unidirectional data flow)의 구조
특성을 알았으니 이제 Redux를 직접 사용해보고 적용해보면서 후기를 작성해보자