[React] 25. 리액트 앱의 state에 대한 또 다른 관점 : 리덕스 vs 리액트 컨텍스트

 

안녕하세요. 박기린 입니다.

이번에는 리액트 앱의 state를 다루는 또 다른 방법에 대해 알아보겠습니다.

 

 

---

리액트에 존재하는 3종류의 state

리액트의 state에는 3종류가 존재합니다.

 

1. Local state 

데이터가 변경되면, 단일한 하나의 컴포넌트에 영향을 미치는 state

 

Ex: 버튼을 누르면 어떤 정보가 표시되고, 한 번 더 누르면 정보가 다시 사라집니다.

-> useState나 useReducer를 사용해서 컴포넌트 안에서 state를 관리합니다.

 

---

 

2. cross-component state

하나의 컴포넌트가 아니라 다수의 컴포넌트에 영향을 미치는 state

 

Ex: 모달 컴포넌트는 다수의 컴포넌트에 영향을 줍니다. 모달 컴포넌트를 여는 버튼은 모달 외부에 존재하고, 모달 안쪽의 버튼을 눌러서 모달창을 닫을 수도 있습니다. 이처럼 다수의 컴포넌트가 협력해서 모달창을 표시하거나 감추는 상황입니다.

-> useState나 useReducer로 구현할 수 있는데, 이때 주변 컴포넌트(모달 컴포넌트 or 모달을 여는 버튼이 있는 컴포넌트)에 props를 전달해야 합니다. 이를 props 체인 또는 props 드릴링이라고 부릅니다.

 

---

 

3. app-wide state

애플리케이션의 모든 컴포넌트에 영향을 미치는 state

 

Ex: 사용자 인증(로그인 정보)가 대표적인 예시입니다. 로그인의 유무는 '로그인 버튼의 유무', '회원 정보 출력 여부' 등을 비롯하여, 컴포넌트 전반에 영향을 미칩니다.

-> useState나 useReducer와 props를 이용해서 관리를 할 수는 있는데 너무 번거롭습니다. 그래서 리액트 컨텍스트(React Context)가 존재합니다. 리액트 컨텍스트는 리액트의 내장 기능으로, cross-component state나 app-wide state를 쉽게 관리하도록 해줍니다. 그리고 리덕스(Redux)도 리액트 컨텍스트와 같은 문제를 해결해줍니다.

 

리덕스와 리액트 컨텍스트 모두 app-wide state인데, 이 둘은 무엇이 다를까요? 리덕스는 외부 라이브러리인데, 굳이 왜 필요한 걸까요?

 

 

 

 

 

---

리덕스 vs 리액트 컨텍스트 (Redux vs React Context)

리액트 컨텍스트에는 '잠재적인 단점'이 있습니다. '잠재적'이다보니 항상 문제가 되는 것은 아니긴 합니다.

+) 참고로 리덕스와 리액트 컨텍스트 둘 다 동시에 사용할 수는 있습니다. 근데 너무 복잡해질 수 있어서 선택과 집중을 해야 합니다.

 

 

리액트 컨텍스트의 단점

1. 리액트 컨텍스트의 사용이 복잡하다는 점

리액트 컨텍스트는 설정이 아주 복잡합니다. 그나마 소형 또는 중형 크기의 앱이면 문제가 안 될 수도 있지만, 기업 수준의 대평 애플리케이션일 경우...

 

    return (
      <AuthContextProvider>
        <ThemeContextProvider>
          <UIInteractionContextProvider>
            <MultiStepFormContextProvider>
              <UserRegistration />
            </MultiStepFormContextProvider>
          </UIInteractionContextProvider>
        </ThemeContextProvider>
      </AuthContextProvider>
    );

위와 같은 끔찍한 코드가 나올 수 있습니다.

 

 

대형 앱일수록 app-wide state나 cross-component state가 많이 존재합니다. 그래서 그런 state들을 관리하기 위한 아주 다양하고 많은 <ContextProvider> 컴포넌트를 사용합니다. 그래서 이런 괴랄한 JSX 코드가 나오게 됩니다.

 

 

물론 다양하고 많은 ContextProvider를 구축할 필요가 없긴 합니다. 큰 Context 하나에 모든 state를 집어넣으면 되긴 합니다. 근데 이렇게 하면, 큰 ContextProivder를 구축하고 관리하는 데에 큰 어려움이 생깁니다.

 

하나의 ContextProvider에 많은 일을 부과해야 합니다. 사용자 인증, 사이트 테마, 사용자의 입력, 모달창 표시 여부 등등 뿐만 아니라, 정말 다양한 것들을 종합적으로 관리하게 됩니다. 더 관리하기 복잡해집니다. 그래서 단점이 됩니다.

 

 

 

 

2. 리액트 컨텍스트를 사용하면 성능(퍼포먼스)에 좋지 않다는 점

리액트 컨텍스트는 다른 잠재적인 단점으로 성능 문제가 있습니다.

 

 

리액트 공식 팀원의 comment에 따르면, 리액트 컨텍스트는 '테마 변경, 사용자 인증'과 같은 업데이트 빈도가 낮은 state에서는 좋지만, 업데이트 빈도가 잦은 (데이터 변경이 잦은) state에는 좋지 않다' 라고 언급되어 있습니다.

 

마지막 문장을 보면, 리액트 컨텍스트는 'Flux-like state propagation'을 대체할 수 없다고 나옵니다. '유동적인 state 전달'의 의미로 해석이 되는데, 리덕스는 유동적인 state 관리 (Flux-like state management) 라이브러리입니다.

즉, 리액트 컨텍스트는 유동적인 state (Flux-like state)에 있어서 리덕스를 훌륭하게 대체할 수 없다고 말하고 있습니다.

 

 

 

다음은 리덕스에 관한 글을 작성하겠습니다.