상태 관리

 

여러 가지 프로젝트를 진행하면서 내가 제일 많이 했던 고민이 바로 "상태 관리"이다.

 

상태 관리를 신경써야 하는 이유는 다양하지만 내가 중요하게 받아드리는 이유는 아래와 같다.

1. 중앙 상태 관리를 통해 컴포넌트 간의 데이터 흐름을 쉽게 관리 가능
2. 코드 유지 보수성 향상
3. 상태의 불변성을 유지함으로서 예측 가능하고 안정적인 어플리케이션 구현 가능

어떻게 상태를 관리하는지에 따라 프로젝트의 성능이 달라진다.

 

 

위와 같은 이유로 프론트엔드 개발자는 특히 상태 관리를 잘해야 한다고 생각한다. (직접적인 영향이 있기 때문에)

 

그래서 오늘은 상태 관리가 뭔지, 어떤 방법으로 하는지에 대해 자세히 알아보려고 한다.

 

상태란?

우선 상태에 대해 찾아봤다.

• 어플리케이션 내에서 변경 가능한 데이터
• 리액트에서는 컴포넌트 내에서 관리되는 데이터를 의미

 

 

상태 관리를 해야하는 이유는?

상태 관리를 해야하는 이유는 위에서도 설명했지만, 중요한 내용이기 때문에 한번 더 정리하고자 한다.

 

아래와 같은 상황이 있다고 가정해보자.

하나의 데이터를 여러 컴포넌트에서 사용해야 해서 해당 데이터를 최상위 컴포넌트에서 props로 넘겨준다.
이 때, 중간에 있는 몇 개의 컴포넌트들은 해당 데이터가 필요하지 않다.

 

이런 경우 중간에 있는 컴포넌트들은 불필요한 데이터를 받아 넘겨주는 작업을 해야 한다.

 

이 과정 중에 휴먼 에러로 통해 데이터 불변성이 깨질 수 있고, 다른 작업자가 데이터를 추적하는 것도 어려워진다.

이런 문제 상황 발생률을 낮추기 위해서 우리는 꼭 상태 관리를 해야 한다!

 

 

상태 관리를 해줘야 하는 데이터는?

지금까지 글을 읽다보면 문뜩 아래와 같은 생각을 할 수도 있을 것이다.

 

"엇 그럼 모든 데이터를 중앙에서 관리하면 안되나?"

이 질문에 대한 대답은 "안된다"이다.

이유는 바로 불필요한 리렌더링을 발생시키기 때문이다.

 

중앙에서 관리되는 데이터가 변경될 때마다 구독중인 모든 컴포넌트가 리렌더링 된다.

만약 중앙에서 모든 데이터를 관리하게 된다면 하나라도 데이터가 변경되면 불필요한 리렌더링이 증가하게 될 것이다.

 

"그럼 중앙에서는 어떤 데이터들을 관리해야 하는 거지??"

바로 바로~! 프로그램 전반에 걸쳐 사용되는 정보들이다.

 

1. 사용자 인증
   • 로그인 상태, 사용자 권한, 토큰 등
2. 테마 및 스타일
   • 전역으로 사용되는 테마, 스타일, 색상 등 -> 일관된 스타일 유지
3. 애플리케이션 설정
   • 사용자가 선택한 애플리케이션 설정, 언어, 알림 등 -> 사용자 경험을 일관되게 유지
4. 데이터 캐시 및 API 응답
   • 서버에서 받아온 데이터, API 응답 결과 -> 불필요한 중복 요청 방지
5. 로깅 및 에러 상태
   • 애플리케이션에서 발생하는 로그 및 에러 -> 안정성 유지

 

 

상태 관리하기

자, 이제 상태 관리를 도와주는 기능 및 라이브러리를 알아보자!

 

Context API

• 리액트에서 제공하는 상태 관리 기능
• 컴포넌트 트리에서 상태를 공유할 수 있음
• 단, 불필요한 리렌더를 발생시키는 경우가 있음

 

Redux

• 상태 관리의 표준으로 자리 잡은 라이브러리
• 중앙 집중식 상태 관리를 제공
• 액션, 리듀서, 스토어 등의 개념을 사용

 

Recoil

• 페이스북에서 개발한 상태 관리 라이브러리
• 중앙 집중식 상태 관리를 제공
• atom, selector 등의 추상화된 개념을 사용

 

 

Redux는 다음에 자세하게 다뤄볼 예정이고, 

Context API, Recoil은 아래 글을 참고하면 좋을 거 같다.

https://hani-develop-history.tistory.com/68

ContextAPI와 Recoil