상태관리
지난 포스트에서는 상태에 대해서 알아보았다.
상태란 데이터 바인딩을 통해 변경되는 데이터를 표현하고자 할 때 사용되는 변수라고 정의했다.
그렇다면 이번엔 상태관리는 무엇이고 왜 중요하다고 계속 언급되는건지 조금 알아보려 한다.
상태관리
상태관리란 해석하자면 말 그대로 상태를 관리하는 작업, 즉 상태를 조작하는 모든 작업을 일컫는 단어이다.
상태란 사용자, 코드, 화면 변화에 의해 언제든지 바뀔 수 있다.
따라서 코드가 방대해질수록 상태의 변화를 파악하는게 어려워질 수 있는데, 이는 불필요한 리렌더링을 일으킬 수 있고,
코드의 유지보수 또한 어렵게 만들 수 있기 때문에 상태관리에 중요도를 높게 두고 있다.
React의 상태관리
React는 단방향 데이터 흐름을 가지는 구조로, Props를 통해서 하위 컴포넌트로만 데이터가 넘어갈 수 있다.
하지만 이로 인해서 값을 받아야하는 컴포넌트가 다수의 하위 컴포넌트 아래에 있다면 Props를 계속해서 내려줘야하는데
이를 Props Drilling이라고 부르며 이는 상태의 추적도, 유지보수도 힘들어지게 된다.
이를 해결하고 보다 편리하게, 효율 좋은 상태관리를 위해 다양한 라이브러리가 나오게 된다.
상태관리 라이브러리
React의 상태관리 라이브러리 중 다수는 FLUX 패턴을 사용한다.
이는 SPA가 MVC패턴을 계속 활용하면서 생기는 문제점인 "Controller 하나가 많은 Model과 View를 관리해야 한다"를
해결하기 위해서 페이스북이 만들어낸 구조이다.
기본적인 구조는 위와 같은 형태로 Action이 발생하면,
Dispatcher로 액션의 정보 객체가 전달되고 그에 따라서 미리 작성해둔 명령을 실행한다.
Store는 데이터, 상태를 담은 저장공간으로 Dispatcher에서 Store에 접근해 동작을 실행하기도 한다.
이렇게 동작들이 완료되면 변경된 사항을 바탕으로 View가 업데이트되며 한 번의 단방향 흐름이 끝나게 된다.
하지만, View에서 Action이 다시 일어나게 되면 이를 처음부터 다시 실행하듯 아래와 같은 구조로 반복된다.
이러한 구조를 가진 상태관리 라이브러리로 Redux, Mobx등이 있고, 그 외에 최근 사용되는 Recoil처럼 다른 구조를 가진 라이브러리도 있다.
Context API
React에서는 왜 이런 전역 상태관리나 다양한 기능을 제공하지 않는가라고 생각할 때,
React에서는 Context라는 기능을 내놓았다.
Context는 트리 단계마다 명시적으로 props를 넘겨주지 않아도 많은 컴포넌트가 값을 공유하게 해준다.
이 값은 상태 뿐만 아니라, 함수, DOM등 다른 값도 들어갈 수 있다.
즉, 다양한 데이터를 React안에서 전역적으로 사용할 수 있게 사용해주는 기능을 의미하는데, 사용법은 여기서 다루지 않겠다.
다만, Context API를 사용해도 여전히 라이브러리보다 사용성이 좋지 못하고, Provider hell이 생기기도 하는 등의 이유로
라이브러리를 사용하는 경우가 많다.
상태관리를 위해
어떠한 라이브러리를 사용하던지 자신에게 맞는 라이브러리를 사용하여 개발하는 것이 좋지만,
상태관리를 위해 라이브러리를 필수적으로 사용하기 보다는 개발을 하면서 생기는 상태관리 문제에 적합한 라이브러리를 찾아보는 과정이
좀 더 필요할 것 같다. 그로인해 생기는 상태관리에 대한 자신의 생각과 좋은 상태관리를 위한 생각을 정리해보는 것도 좋을 것 같다.
추가로, 우아한테크코스의 영상을 참조해 좋은 상태관리를 위한 전략 3가지를 아래에 기입하겠다.
- 무분별한 전역 상태관리 지양.
- 상태 코드는 연관 컴포넌트들과 최대한 가까이 배치.
- 서버의 데이터를 전역 상태에 저장할 때에는 명확한 전략 확보.
