[React] 상태 관리 라이브러리의 이해 - Redux 동작 원리

React에서 상태 관리 라이브러리를 쓰는 이유?

React는 여러 컴포넌트로 구성되어있다. 각각의 컴포넌트마다 state가 있을 수 있고, useState 같은 hook으로 상태를 관리할 수 있다.

state가 변경되면 컴포넌트가 리렌더링되어 변하게 된다.

리액트는 단방향 데이터 흐름, 즉 부모 -> 자식으로만 데이터가 전달이 가능하기 때문에 자식 컴포넌트도 state에 맞게 변경하려고 한다면 props로 전달해야 한다. 만약 자식 컴포넌트에서도 props로 받은 state를 변경가능하게 하려면 state 변경 함수 또한 props로 전달받아야 한다.

// 부모 컴포넌트
function ParentComponent() {
  const [name, setName] = useState('Parent Name');

  return <ChildComponent name={name} setName={setName} />;
}

// 자식 컴포넌트
function ChildComponent(props) {
  return (
    <div>
      <p>부모 이름:{props.name}</p>
      <button onClick={() => props.setName('')}>초기화</button>
    </div>
  );
}

위 코드에서는 state를 공유하기 위해 부모에서 자식 컴포넌트로 한 번 전달했지만, 만약 그 깊이가 깊어진다면 state 관리가 어렵고 가독성이 떨어질 것이다. 이것을 과도한 props drilling이라고 한다. 

https://dev.to/stuxnat/final-react-project-2poi

이 문제를 해결하기 위해 전역 상태를 관리하는 라이브러리를 사용하게 된다.

대표적인 라이브러리로 Redux가 있다.

 

Redux 동작 원리

Flux 패턴

Flux는 React, Redux의 디자인 패턴이다. 먼저 Flux 패턴에 대해 알아보자.

MVC 패턴은 하나의 변경이 다수의 변경을 일으킬 수 있어 데이터 흐름을 제대로 파악할 수 없는 문제가 있었다. 이런 문제를 해결하기 위해 만들어진 것이 바로 Flux 패턴이다. 단방향 데이터 흐름으로 설계되어있기 때문에 위의 문제를 해결할 수 있게 되었다.

 

Action (Action Creator)

- 새로운 데이터를 포함하고 있는 간단한 객체

- type 프로퍼티로 Action을 구분하고 넘겨받은 값인 payload를 가짐

- Action Creator는 기존 state를 변경하기 위한 액션의 생성을 담당하고 해당 액션을 생성해서 Dispatcher로 넘겨줌

Dispatcher

- 애플리케이션의 모든 데이터 흐름을 관리하는 중앙 허브

- Action의 type과는 관계없이 등록된 모든 Store에 Action을 보냄 => Store에서 Action 처리를 결정

- 동기적으로 처리 => 우선순위가 높은 Action 순으로 처리

Store

- 애플리케이션의 모든 state와 관련 로직을 가지고 있음

- 모든 state 변경은 Store에 의해서 결정됨

- 자체적으로 state 변경은 불가능

View, Controller View

- Controller View는 Store와 View 사이의 중간자 역할을 함

- View는 변화된 state에 따라 다시 렌더링됨

 

 

Redux에서의 Flux 패턴

기존의 Flux와 차이점은 Dispatcher 대신 Reducer로 state 변경 로직을 관리한다. 그리고 단 하나의 Store를 가지며 State tree로 상태값을 유지한다.

Reducer

- Root Reducer: 상태 객체의 key를 기준으로 나누어서 Sub Reducer에게 보냄. 그 후 Sub Reducer들에게 받은 state 객체를 취합해서 Store로 보냄

- Sub Reducer: 이전 state를 변경하지 않고 복사해서 변경 후 Root Reducer에게 돌려줌

https://www.freecodecamp.org/news/what-is-redux-store-actions-reducers-explained/

 

Context API와 Redux의 차이?

Context API는 상태 관리 도구가 아니다. 그저 전역적으로 state를 공유하는 기능만 수행한다. 상태 관리는 사실상 useState, useReducer가 해준다. 하지만 Redux는 상태 관리를 한다.

그리고 Context API는 Provider로 컴포넌트들을 감싸는데 context 값이 변경되면 리렌더링이 된다. 하지만 Redux는 state를 컴포넌트에 종속시키지 않고 외부에서 처리하기 때문에 리렌더링 면에서도 이점이 있다.

 

그럼 Context API는 언제 쓸까?

state 변경이 거의 일어나지 않으면서 전역적으로 사용이 필요한 것들이 있을 때에 적합하다.

예를 들어 locale이나 theme 정보 등이 있다.

 

참고

https://facebook.github.io/flux/docs/in-depth-overview

In-Depth Overview | Flux

https://baeharam.netlify.app/posts/architecture/flux-redux

[Architecture] Flux와 Redux에 대한 이해 - 배하람의 블로그

https://hong-jh.tistory.com/entry/Context-API%EB%8A%94-%EC%99%9C-%EC%93%B0%EA%B3%A0-%EA%B7%B8%EB%A0%87%EB%8B%A4%EB%A9%B4-Redux%EB%8A%94-%ED%95%84%EC%9A%94%EC%97%86%EC%9D%84%EA%B9%8C

Context API는 왜 쓰고, 그렇다면 Redux는 필요없을까?