전역 상태 관리에 대한 고찰

전역 상태 관리가 필요한 상황

props drilling이 과도하게 일어나서, 중간 컴포넌트가 자신과 상관 없는 props를 들고 있어야하는 경우에 전역 상태 관리가 필요해진다.

    A
   / \
  B   C
 / \ / \
D  E F  G

컴포넌트 트리가 다음과 같이 구성되어 있다고 하자. D, E에서 데이터에 대한 접근이 필요하고, F, G에서 데이터를 변경하는 action에 대한 접근이 필요하다고 해보자. 그러면 B와 C에서는 자기 책임이 아닌 action들까지 자식 컴포넌트에 내려줘야하는 문제가 발생하여, 유지보수가 힘들어진다.

전역

전역 상태 관리를 위한 두가지 요소

전역 상태 관리를 수행하기 위해 필요한 요소를 두가지로 분해해볼 수 있다.

상태 관리

데이터 주입

context를

전역 상태 관리의 두 부분

• 상태 관리: 상태에 대한 getter와 setter
• 데이터 주입: 정의된 상태를 컴포넌트들이 쓸 수 있게 넘겨주는 과정

context는 데이터를 특정 컴포넌트 트리에 주입시킬 수 있는 '데이터 주입' 툴에 해당한다. 따라서 context를 통해 전역 상태 관리를 하겠다면 상태를 선언하고 이를 같이 주입해줄 수 있어야한다.

export const [ThemeProvider, useTheme] = buildContext<{ color: 'dark' | 'light' }>('ThemeContext', {
  color: 'light'
});

export funtion App({ Component, pageProps }) {
  return (
    <ThemeProvider>
      <Component {...pageProps} />
    </ThemeProvider>
  )
}

접근 제어성

• 부스 생성 상태의 경우 생성 페이지, 수정 상태의 경우
• useFormContext()

리렌더링

contex

전역 상태로 빼는 기준

1. deeply nested object
2. 접근 제어 목적인지, 모든 애플리케이션에서 공유 목적인지

TL;DR

전역 상태 관리를 수행하기 위해 두가지 요소가 필요하다.

1. 상태 관리
2. 데이터 주입

Context는 데이터를 특정 컴포넌트 트리에서 접근할 수 있게 만드는 접근 제어자. 전역 상태관리에 쓴다면 (2)만 수행.

전역 상태 관리 라이브러리는 (1)과 (2)를 전부 수행하는데, 기본적으로 전역으로 데이터가 접근 가능하다.(global store)

언제, 무엇을 사용할까?

• 전달해야되는 데이터가 간단하고, 특정 컴포넌트 트리로 한정 => context로 주입만 해도 문제 해결
• 전달해야되는 데이터가 간단하고, 전역에서 쓰고 싶음 => context도 ok, jotai도 써볼만함
• 전달해야되는 데이터가 복잡하다 => 전역상태관리를 통해 devtools 디버깅, 리렌더링 최적화 같은 기능 사용 가능
  • 예) deeply nested object 이거나, 상태 바꾸는 action 여러개 정의해야 함.
• 전달해야되는 데이터가 복잡하고, 특정 컴포넌트 트리에 가두고 싶다 => 전역 상태 관리 도구로 상태 정의하고, context로 접근 제어하는 방향으로 두개를 혼용해서 사용 가능하다.