전역 상태 관리

1abme·2023년 4월 21일

상태

상태란 변하는 데이터이며 프론트엔드 개발에서는 UI에 동적으로 표현되는 데이터를 의미한다.
위의 이미지는 쇼핑몰 장바구니화면에서의 상태를 나타낸 것이다.

"장바구니에 담기"와 같은 버튼을 눌러, 해당 물품을 장바구니에 추가할 수 있습니다. 동적인 데이터이므로 이것은 상태입니다.
상단에 [일반구매/정기배송]중 현재 선택된 탭이 무엇인지 나타내는 상태가 있을 수 있습니다.
상품 선택 여부에 따라 주문 금액이나 배송비가 달라집니다. 선택 여부는 변할 수 있으므로 상태입니다.
상품 수량도 상태입니다.
이를 컴포넌트로 분리해 컴포넌트 사이에 어떤 상태를 공유하고 주고 받는지도 생각해보길 바란다.

Side Effect

상태를 다룰 때에 주요 고려 대상인 Side Effect는 함수의 입력 외에도 함수의 결과에 영향을 미치는 요인으로 대표적으로 네트워크 요청, API호출이 있다.

side Effect 최대한 배제하기

컴포넌트를 만들시에는 Side Effect를 최대한 배제하고 컴포넌트를 만들어야한다. 더욱 자세히 말해보자면 입력 데이터가 가짜 데이터라 할지라도 컴포넌트는 표현(presentation)할 수 있어야하며 이러한 컴포넌트를 presentation 컴포넌트라고 부른다.

불가피한 Side Effect와 상태

Side Effect를 최대한 배제하고 컴포넌트를 만들어야하지만 불가피하게 생기는 경우가 있을 수 있다. 예를들어 "로딩 중" 을 나타내는 상태는 데이터 전송 여부에 달려있기 때문에 이 상태는 Side Effect 에 의존적이라고 할 수 있다.

상태의 두가지 구분

상태를 구분하는 데에 절대적인 기준이나 법칙은 없지만 로컬 상태, 전역 상태로 나눠서 접근해 볼 수 있다. 이 두 상태를 간단히 설명해보자면 아래와 같다.

로컬상태 : 특정 컴포넌트 안에서만 관리되는 상태
전역상태 ; 프로덕트 전체 혹은 여러가지 컴포넌트가 동시에 관리되는 상태

로컬상태

로컬상태는 보통 컴포넌트 내에서만 영향을 끼치는 상태를 일컫는다. 대표적으로 다른 컴포넌트와 데이터를 공유하지 않는 폼(form) 데이터는 대부분 로컬상태이다. input box, select box 등과 같이 입력값을 받는 경우가 이에 해당한다.

전역상태

전역상태는 다른 컴포넌트와 상태를 공유하고 영향을 끼치는 상태이다. JavaScript에서 전역변수를 남용하는 것을 좋지 않지만 경우에 따라서는 전역상태가 필요하다.

우선 서로 다른 컴포넌트가 사용하는 상태의 종류가 다르다면 꼭 전역상태일 필요없이 서로 다른 출처 (source)가 있어도 상관없다. 예를들어 장바구니 물품과 회원정보는 사용하는 상태의 종류가 다르기에 출처가 다르다.

하지만 서로 다른 컴포넌트가 동일한 상태를 다룬다면 이 출처는 오직 한곳이어야 한다. 만일 출처의 사본을 사용하는 경우 두 데이터는 서로 동기화(sync)하는 과정이 필요한데 이는 오히려 복잡한 코드를 야기할 수 있다. 때문에 한곳에서만 상태를 저장하고 접근할필요가 있다. 여기서 '하나의 출처'는 다른말로 이야기하자면 '전역공간'이라고 볼 수 있다.

전역상태에서의 데이터 무결성

데이터 무결성이란 데이터의 정확성을 보장하기 위해 데이터의 변경이나 수정 시 제한을 두어 안정성을 저해하는 요소를 막고 데이터 상태들을 항상 옳게 유지하는 것이다.

이 무결성을 위한 방법론은 "Single source of truth"(신뢰할 수 있는 단일출처)로 '동일한 데이터는 항상 같은 곳에서 데이터를 가지고 온다.'를 원칙으로 하고 있다.

전역상태 관리의 예

전역으로 상태를 관리해야 하는 경우의 예중 하나로 다크모드를 떠올려볼 수 있다. 요즈음 여러 사이트에서 다크 모드 기능을 지원하고 있는데 이 경우 모든 페이지, 모든 컴포넌트에 다크모드 혹은 라이트 모드가 적용 되어야 하기 때문에 이러한 테마 설정상태를 전역으로 관리해야 한다.

국제화(Globalization) 설정도 마찬가지이다. 사용자가 사용하는 브라우저나 운영체제가 특정 언어사용을 인지하고 UI에 필요한 텍스트 리소스를 따로 저장한 후 전역 상태로 관리하기도 한다. 이 기능의 경우 모든 컴포넌트에서 사용자의 언어로 표현이 되어야 하기 때문에 전역에서 상태 관리가 필요하다.

조금 더 복잡 한 예를 생각해보자면 포토샵이나 일러스트레이터에는 히스토리 기능과 Undo/Redo를 지원한다. Undo/Redo, 히스토리 기능의 작동 원리는 이렇다. 화면에 표시되는 모든 내용을 전부 상태 객체로 만들어 저장해버린다면 원하는 특정 상태를 바탕으로 컴포넌트르 표현할 수도 있다.

상태관리 툴

React Context
Redux
MobX

상태 관리 라이브러리 사용시 장점

전역상태를 위한 저장소 제공
props drilling 문제를 해결
- 예를들어 <A> 라는 컴포넌트에 상태가 있고 <I> 라는 컴포넌트가 해당상태를 사용한다고 하면 그중간에 존재하는 <C>, <G> 등은 굳이 name 이라는 상태가 필요하지 않음에도 컴포넌트에 props 를 만들어 자식 컴포넌트에 넘겨 주어야했다. 이를 props drrilling 문제라고 부른다.

상태관리 툴이 반드시 필요한 것은 아니다. React 공식문서의 React로 사고하기 만 잘 참고하여 사용해도 대부분의 문제를 해결할 수 있기에 장단점을 분명히 인지하고 상태관리 툴 사용 여부를 결정하기 바란다.