Intro
이전에 Openlayers를 사용해서 프로젝트 수행할 때 리액트를 처음으로 써봤다. 그때 당시 Vue3만 써봤었는데 (Vue3를 먼저 쓰게된건 나의 이 홍대병때문에..) 한국의 개발 시장에 전반적으로 리액트가 높은 비중으로 요구되는 것을보고 리액트도 한번 써보자해서 리액트로 프로젝트를 간단하게 만들었다.
그때 당시에도 Nextjs가 있었지만 리액트도 처음인데 Nextjs까지 하기엔 프로젝트 기한이 압박으로 다가왔고 리액트만 적용했다.
작은 프로젝트여서 그런지 상태 관리가 필요하지 않았고 불편함은 크게 못느끼고 다만, 문법이 Vue3보다 어렵다라는 것만 느끼고 넘어갔다.
요즘 구인글보면 리액트에 상태관리 Redux, recoil 등을 써본 경험을 요구하는 경우가 많다.
그래서 궁금해졌다. 아니 '상태 관리', '상태 관리' 하는데
대체 '상태'는 뭐고 '상태 관리'는 뭐야??
그래서 지금부터 알아보자
State(상태)
컴포넌트의 동적인 데이터
상태의 변경이 컴포넌트의 렌더링과 상호 작용에 영향을 미친다.
리액트에서 기본적으로 상태를 관리할 수 있는 수단들이 있다.
useState, useReducer, Context API 등...
하지만 왜 Redux, recoil, mobx와 같은 제3의 라이브러리로 상태를 관리하게 됐을까??
State management(상태 관리)
상태관리의 필요성
앞선 글에서 알아봤듯이 리액트는 가상DOM을 이용해서 DOM의 변화를 조정(Reconciliation)하고 반영한다. 이때 컴포넌트들이 10개 아니 1억 단계로 중첩돼있다고 가정해보자. 1번 컴포넌트에서 사용된 State가 1억번째 컴포넌트에서 필요한 경우. 1억 단계를 props로 계~~~속 전달해줘야한다.
(이렇게 컴포넌트 간에 props 단계가 깊이 전달되는 것을 Prop Drilling이라 함.)
이런 비효율을 개선하기 위해 전역 상태가 필요해졌다.
- 컴포넌트 간 데이터 공유 - ex) 로그인 상태, 언어, 테마 설정
- 상태의 일관성 유지 - 여러 컴포넌트에서 동일한 상태에 접근하므로 일관성 유지
- 복잡성 관리 - 1억개 컴포넌트의 상태를 개별적으로 관리하는 것은 어렵다
- 컴포넌트 간 분리 - 컴포넌트의 재사용성을 높임
- 비동기 상태 관리 - 비동기 작업 처리 시, 여러 컴포넌트에서 상태에 접근하고 업데이트 가능
라이브러리가 필요한가
전역 상태? 그럼 Context로 만들면 되는거 아니야??
맞는 말이다. 하지만 Context API는 높은 빈도로 갱신되는 앱에서 성능 이슈가 존재하기에 전역 상태 관리가 필요해진 것 이다.
+상태 관리 라이브러리는 전역 상태 관리뿐 아니라 다른 추가 편의 요소들이 많다.
전역 상태 관리'만' 필요하다면 Context API를 쓰는것이 나쁜 선택은 아니다.
어떤 라이브러리나 프레임워크를 도입할 때 등장한 배경과 왜 필요한지 아는 것이 중요하다. 그런 측면에서 아래 글도 읽어 볼만 할 것 같다.
You Might Not Need Redux
닭잡는데 소잡는 칼 쓰지말자
참고자료
https://suzzeong.tistory.com/91 (⭐)
https://velog.io/@cada/React-Redux-vs-Context-API
https://blog.thelumayi.com/78 (⭐)
https://yukihirahole.tistory.com/155#gsc.tab=0
