220606 [React] 리액트 상태관리와 전역관리의 필요성
상태(state)란 무엇인가?
정의를 여러가지로 찾아보았지만 그중 가장 이해가 되는 정의를 인용해본다.
웹 애플리케이션을 렌더(render)하는데 있어 영향을 미칠 수 있는 값
Plain Javascript Object hold information influences the output of render
*리액트 공식문서 중 내용에도 위와 같이 설명한다. (참고 링크)
이 말 전부 다 통용 되지는 않겠지만 리액트를 사용함에 있어서 이해가 잘되는 정의였고,
조금 더 쉽게 풀어쓴다면 페이지가 그려질 때 그려지는 일련의 내용물 정도로 말할 수 있다고 생각한다.
전역관리 사용의 이유?
상태관리에 더 관심을 가지게 된 계기는 팀 프로젝트를 진행함에 있어
props drilling을 직접 경험하게 되었기 때문이다.
아래 사진에 보면 사이트에 그룹러닝을 위한 게시물을 등록할 시 총 3단계에 나눠서 게시물 등록이 이루어 졌다.
이러다 보니 이전단계/다음단계로 단계가 바뀔때마다 값이 유지되어야하고 맨 위의 부모컴포넌트에서 등록 요청이 되는 값들이 모이게 되다보니 상태 끌어올리기와 props로는 계층구조가 너무 깊어지고 컴포넌트가 많아질 수록 번거로움이 느는 상황이 발생했다.
이를 변경하기 위해 컴포넌트 합성, Context API, 전역관리 라이브러리로 가능하다는 것을 알게되었고
그중에서 사용경험이 있고 상태관리의 복잡성 부분에 초점을 맞춰 전역으로 다뤄야 할 필요성을 느꼈기에 Redux를 사용하였다.
*Recoil, Mobx도 있었지만 검색 시 자료가 가장 많이나오고 초창기에 나와 새로운 라이브러리들이 Redux의 어떤점을 보완하기 나온지를 알기 위해 Reudx를 채택
여기서 잠깐 리액트에서 Context API에 대해 잠시 정리하고 가보려한다.
아직 공부가 많이 필요한 부분이지만 하기 잘 정리한 사이트가 있어 참고해서 기록한다.
리액트에서 상태관리의 복잡성은 Context API가 도입됨에 따라 어느정도 해소가 되었다고 한다. 그렇지만 Context API는 성능적인 이슈가 아직 존재한다.값에 변화가 발생했을 때 Context를 구독하고 있는 모든 컴포넌트들이 전체적으로 모두 리-렌더링이 발생한다. 따라서 반복적이고 복잡한 업데이트와 관련된 부분에서는 비효율적일 수 있다.
반면 Redux의 경우에는 자체적으로 리-렌더링과 관련된 부분에 최적화가 적용되어 있기 때문에, 부분적인 리-렌더링이 발생한다. 또한 리덕스를 사용한다면 Context API에선 제공할 수 없는 여러 다양한 기능들을 미들웨어를 사용해 관리할 수 있는 장점 또한 존재한다.
물론 이러한 성능적인 이유는 useReducer를 통한 변경 흐름 조절이나 메모이제이션을 활용, 또는 논리적 관점에서
Provider를 여러 개로 분리하고, 가능한 그 상태를 필요로 하는 곳 근처에 두는 등 자체적인 최적화가 가능하지만 이러한 과정이 다소 번거롭게 작용할 수 있다.
결국엔 전역관리를 통함이 상태관리를 효율적으로 하는데 좋은것이지만 여러개의 라이브러리들이 있고 그중에 해당 라이브러리를 선택하는 이유에대해서는 고민을 해봐야할것이다. 다음 글에서는 Rudux의 선택 이유와 사용 후기에 대해 더 자세히 다뤄보도록 해야겠다.