우아한테크코스 테코톡
온스타의 상태관리
카테고리 : 우아한테크코스 테코톡
온스타의 상태관리
상태란?
- 유저와의 상호작용을 위한, 변할 수 있는 데이터
상태 관리란?
- 유저에게 UI/UX 제공
- 유저와 데이터 주고 받기
- 유저와의 상호작용을 위해, 상태를 조작하고 다루는 모든 작업
상태관리가 중요한 이유
- 상태는 언제든지 유저의 상호작용 혹은 화면의 변화에 따라서 비동기적으로, 지속적으로 변할 수 있다. 서비스가 방대해지고 하는 역할들이 많아지다보면 상태가 언제? 어디서? 왜 변경되는지 추적하기 힘들 수 있다. 그래서 적절한 상태관리가 필요하다.
- 적절한 상태 관리가 실패하면 상태들은 불필요한 릭 렌더링을 발생시킬 수 있고, 의도하지 않은 UI/UX를 발생시킬 수 있고, 유지 보수하기 힘든 코드를 작성해서 유지보수가 힘들어진다.
과거의 상태 관리
- 제이쿼리 코드에서는 HTML의 데이터 어트리뷰트를 사용해서 DOM 앨리먼트에 직접 상태를 주입하고 사용하는 곳에서 데이터 어트리뷰트에 있는 데이터를 받아와서 사용하곤 했다.
- 그러다 보니까 상태 관리 로직이 DOM 중심으로 구성이 되게 됐다.
- 이런 상태가 어디서? 언제? 왜? 발생했는지 추적하기 힘들다.
- 유지보수가 힘들다.
SPA의 등장
- 유저들은 즉가적인 상호작용을 원하게 되고 더 나은 UX를 원하게 됐다
- 유저들의 니즈에 맞춰 프런트엔드 개발자들은 SPA를 등장시켰고 SPA가 주가 되었다.
SPA의 상태관리
- SPA를 지원하는 프레임워크와 라이브러리들은 DOM에 접근 없이도 데이터가 변경되면은 값을 변경할 수 있도록 지원을 하고 있다.
- 이를 통해서 기존에 DOM 중심이던 상태관리 로직이 데이터 중심의 상태관리 로직이 되었다.
- 이를 통해서 어디에서 상태가 변화했는지 추적이 유리하게 되었다고 할 수 있다.
리액트의 상태관리
- 리액트는 양방샹의 데이터 흐름을 가지는 MVC와는 다르게 단방향의 데이터 흐름을 가진다.
- 상위 컴포넌트에서 State를 가지고 해상 상태를 저장하면서 의존된 컴포넌트가 있다고 하면은 Props로 해당 상태를 넘기게 된다.
- 의존된 컴포넌트가 더 많다면 받은 props에 있는 상태를 다른 props로 넘기게 되고 해당 작업을 반복하게 되면서 상태관리를 하게 될 것이다.
- 이 문제는 다시 상태 관리가 어디서 언제 왜 변경되는지 추적하기 힘들어지게 되고 이 문제를 Prop Drilling 라고 한다.
- Prop Drilling을 해결하기 위해 Redux 가 등장했다.
- Redux
- Redux 는 Flux 아키텍처와 Reducer의 개념을 합쳐서 만든 전역 상태관리 라이브러리라고 할 수 있다.
- 의존되는 컴포넌트들을 분리할 수 있게 되었다.
- Redux DevTools (상태 변화 추적) 라는 강력한 개발자 도구를 지원 하는데 이를 통해서 상태가 어디서 언제 왜 변경됐는지 추적하기 쉬워졌다.
- 단점
- Redux 를 사용하려면 많은 코드를 작성해야 되는 수많은 보일러 플레이트 코드가 있다.
- API 통신 관련되 코드를 전역적으로 관리를 하게 되는데 이 상황을 피치 못하게 되었다.
- 그래서 수 많은 상태 관리 라이브러리가 등장했다.
좋은 리액트 상태 관리란? (발표자의 주관)
- 무분별한 전역 상태관리는 피하자.
- 일반적인 리액트의 상태관리는 지역적인 상태 관리로 지역적인 상태로 가지고 있는데 Prop Drilling 을 발생시킬 수 있다.
- 합성 컴포넌트를 적절히 활용하여 Prop Drilling 을 해소할 수 있다. 재사용성도 꾀할 수 있다.
- 서버의 데이터를 전역 상태에 저장할 때는 명확한 전략을 갖자.
- 명확한 전략이 없다면, 라이브러리를 똑똑하게 활용하자.
- 상태 코드는 연관 컴포넌트들과 최대한 가까이 배치하자. (State Colocation)
- 하나의 컴포넌트가 많은 상태를 가지고 있다면. 해당 컴포넌트가 너무 많은 일을 하는 것은 아닌지 살펴보자.
