전역상태관리는 뭐가좋을까?(Redux,Zustand,Mobx)

👋 왜 전역상태관리를 해야할까?

React의 사용목적 상 component로 만들어 기능을 구현하고 page를 라우트 처리해서 사용하는 경우가 정말 많다. 그러다보면 데이터를 부모->자식에게 전달하게 된다. ex. 게시글의 id값, 쇼핑몰 구매 수량 등

그런데 상태관리(= 데이터를 전달/변경하는 과정) 시 여러가지 문제에 부딪히는데 몇 가지를 소개하자면

상태관리 시 문제점
1.부모-> 자식에게만 데이터를 전달할 수 있다.(일반적으로)
2.Props drilling으로 인해 코드가 복잡해진다. (아래의 Children이 100개라면...? 한개의 상태를 100번 건네줘야함)
3.상태가 변경되면 체인된 모든 컴포넌트가 재랜더링된다.(Children3의 상태가 변경되면 Ch2,Ch1,Parent 도 재랜더링 됨)

//Parent.jsx(Props로 상태전달)

const Parents = () => {
    const [state,setstate] = useState('효도 좀 하고 살자')
  return  <Children1 data={state}></Children1>
}

//Children1.jsx
const Children1 = (props) => {
  return <Children2 data={props.data}></Children2>
}

//Children2.jsx
const Children2 = (props) => {
  return <Children3 data={props.data}></Children3>
}

//Childrens3.jsx
const Children3 = (props) => {
  return <div>{props.data}</div>
}

 

위와 같은 문제점들을 해결하기 위해 전역적으로 상태를 관리할 수 있는 라이브러리가 생겨났다.

---

🌈 전역상태관리 라이브러리는 뭐가 있을까?

아래는 npm trends에서 상태관리 라이브러리를 비교한 지표이다. 한 해 동안 다운로드량을 비교해준다.

 

1등 Redux (9,200,000)

2등 Zustnad (3,100,000)

3등 Mobx(1,200,000)

4등 jotai 5등 recoil

 

🌈 상태관리의 접근방식

상태관리 라이브러리의 접근 방식을 3가지로 나눠볼 수 있는데 : 

 

Flux (Redux, Zustand)

• Flux 패턴은 상태 관리의 전통적인 방식으로, 액션(Action), 디스패처(Dispatcher), 스토어(Store), 그리고 뷰(View)로 구성된다.
• Redux와 Zustand는 Flux 패턴을 기반으로 한 상태 관리 라이브러리인데 Redux는 불변성과 단방향 데이터 흐름을 강조하며, Zustand는 간소한 API와 함수형 스타일을 강조한다.

장점:

• 액션과 리듀서를 통한 명시적인 상태 변경으로 상태 변화를 추적하고 디버깅하기 쉽다.
• 중앙 집중식 상태 관리로 상태의 일관성을 유지하고 버그를 방지할 수 있음.

단점:

• 복잡한 상태 관리 시나리오에서 불필요한 코드나 중복이 발생할 수 있다.
• 초기 학습 곡선이 다소 높을 수 있음.

 

Proxy (Mobx, Valtio)

• Proxy 기반의 상태 관리 라이브러리들은 자바스크립트의 Proxy 객체를 활용하여 객체의 변경을 감지하고 반응하여 상태를 업데이트한다.
• MobX는 객체와 배열을 감시하고, 해당 객체의 속성이나 요소가 변경될 때 자동으로 리렌더링됨.
• Valtio는 MobX와 유사하지만, React 상태 관리 라이브러리인 Jotai와 함께 사용될 수 있도록 설계되었다.

장점:

• 변경을 감지하고 반응하는 동적인 방식으로 상태 관리를 수행할 수 있다.
• 상태를 수정하는 과정이 간단하고 직관적.

단점:

• 객체의 속성 변경만 감지할 수 있기 때문에 객체가 아닌 다른 유형의 상태 변화를 감지하기 어려울 수 있음.
• 복잡한 상태의 관리는 일부 복잡성을 유발할 수 있다.

 

Atomic (Jotai, Recoil)

• Atomic 상태 관리는 리액트 컴포넌트 트리 안에서 상태를 원자적* 으로 관리하는 방식이다.
• Jotai는 리액트의 useContext 훅과 함께 사용되며, 컴포넌트 간의 상태 공유를 위한 간단하고 직관적인 API를 제공함.
• Recoil은 페이스북에서 개발한 상태 관리 라이브러리로, 컴포넌트 간의 전역 상태를 효과적으로 관리할 수 있도록 지원함.

장점:

• 컴포넌트 간에 독립적인 상태 관리를 통해 상태의 일관성을 유지할 수 있음.
• 상태를 더 세밀하게 관리하고, 상태의 변경이 해당 컴포넌트로 제한되기 때문에 성능이 향상될 수 있음.

단점:

• 전역 상태를 관리하기에는 한계가 있을 수 있다.
• 컴포넌트 간의 상태 공유가 복잡한 경우에는 추가적인 관리가 필요할 수 있다.

원자적이란?

상태가 각각의 작은 단위로 나뉘어 관리되고, 이러한 작은 단위의 상태가 동시에 업데이트되어야 할 때 전체적으로 일어나야 하는 상태의 일관성을 보장하는 것

 

그렇다면 가장 많이 사용하는 세가지의 라이브러리를 어떻게 사용하지 알아보자.

---

🌼 Redux : 구관이 명관

ㅇ 기본용어정리

-액션(Action)

애플리케이션에서 스토어로 보내는 데이터 묶음.

-리듀서(Reducer)

리듀서는 애플리케이션의 상태를 변경하는 함수. 이전 상태와 액션을 받아 새로운 상태를 반환함.

-스토어(Store)

애플리케이션의 상태를 담고 있는 객체. 스토어는 애플리케이션의 상태를 감시하고, 리듀서를 통해 상태를 업데이트하며, 상태를 변경한 후에 알림.

-디스패치(Dispatch)

액션을 발생시키는 역할을 함. 디스패치는 액션을 받아 스토어에 전달하고, 이후 리듀서가 호출되어 상태를 업데이트함.

장점:

• 예측 가능한 상태 관리:  단일 상태 트리를 사용하여 전체 상태를 관리한다. 상태의 변화가 예측 가능하며, 디버깅이 쉽다.
• 확장성: 중앙 집중식 스토어를 사용하여 애플리케이션의 상태를 관리함. 이는 여러 컴포넌트에서 쉽게 접근하고 변경할 수 있어서 대규모 프로젝트에서 용이함.
• 컴포넌트 분리: 상태를 완전히 독립적인 컴포넌트로 분리시킨다. 이는 애플리케이션의 각 부분이 독립적으로 테스트되고 재사용될 수 있음.

단점:

• 러닝커브: 처음에 학습하기 어렵다 복잡하기 때문. 액션, 리듀서, 미들웨어 등의 개념을 이해해야 하며, 초기 설정 및 구성이 필요함.
• 불필요한 보일러플레이트* 코드: Redux를 사용하면 애플리케이션에서 상태 변화를 처리하는 데 필요한 많은 보일러플레이트 코드가 발생할 수 있는데 이는 작은 프로젝트에서는 불필요하게 복잡해짐.

보일러 플레이트란?

새로운 프로젝트를 시작할 때 필요한 기본적인 코드나 구조를 제공하는 초기 설정이나 템플릿을 의미(React의 CRA 같은 것)

import { createStore } from 'redux';

// 초기 상태 정의
const initialState = {
  count: 0
};

// 리듀서 정의
function reducer(state = initialState, action) {
  switch (action.type) {
    case 'INCREMENT':
      return { ...state, count: state.count + 1 };
    default:
      return state;
  }
}

// 스토어 생성
const store = createStore(reducer);

// 컴포넌트에서 상태 변경을 위한 액션 디스패치
store.dispatch({ type: 'INCREMENT' });

 

 

 

---

🌼 Zustand : simple is best

import { create } from 'zustand'

const useCountStore = create((set) => ({
  count: 0,
  increment: (qty) => set((state) => ({ count: state.count + qty })),
  decrement: (qty) => set((state) => ({ count: state.count - qty })),
}))

const Component = () => {
  const count = useCountStore((state) => state.count)
  const increment = useCountStore((state) => state.increment)
  const decrement = useCountStore((state) => state.decrement)
  // ...
}

장점:

• 간결함: Zustand는 Redux보다 훨씬 간단하고 직관적이다. 상태 관리를 위한 별도의 리듀서나 액션 생성자를 작성할 필요가 없음.
• 선택적 불변성: Zustand는 불변성을 강제하지 않는다. 이는 작은 규모의 애플리케이션에서는 상태 업데이트를 더 편리하게 만들 수 있음.
• 성능: Zustand는 단순한 상태 관리 도구로서 Redux보다 가볍고 빠르다. 이는 작은 규모의 애플리케이션에서 불필요한 복잡성을 줄여줌.

단점:

• 상태 공유의 어려움: Zustand는 각 컴포넌트의 지역 상태를 관리하는 데에 적합함. 그러나 여러 컴포넌트 간에 상태를 공유하고 동기화해야 하는 경우에는 추가적인 작업이 필요하다.
• 커뮤니티와 생태계의 크기: Zustand는 Redux만큼 큰 사용자 커뮤니티나 다양한 생태계를 가지고 있지 않음. 
• 유연성의 부족: Zustand는 React에 특화되어 있으며, 다른 라이브러리와의 호환에 추가 설정이 필요할 수도 있다. 만약 향후 다른 프레임워크로의 마이그레이션이 예상된다면 이를 고려해야 함.

 

 

 

---

🌼 Mobx : Always, i will see you

import { observable, action, computed } from 'mobx';

// observable 상태 정의
const counterState = observable({
  count: 0,
});

// action으로 상태 변경 메서드 정의
const increment = action(() => {
  counterState.count++;
});

// computed를 사용하여 파생된 값 계산
const doubleCount = computed(() => {
  return counterState.count * 2;
});

// 상태 변경 메서드 호출
increment();

// 파생된 값 조회
console.log(doubleCount.get()); // 출력: 2

 

장점:

• 간단함: MobX는 간단하고 직관적인 API를  제공한다. 자동으로 상태 업데이트를 관리함.
• 반응성: MobX는 관찰 가능한 상태와 의존성 그래프를 사용하여 상태 변경을 감지하고 자동으로 업데이트함.
• 유연성: MobX는 Redux와 달리 액션, 리듀서, 디스패처 등의 개념이 필요하지 않아서 유지보수가 더 간편하다.

단점:

• 러닝 커브: MobX의 개념과 동작 방식을 처음에 이해하기 어려울 수 있음. 특히 MobX의 관찰 가능한 상태와 의존성 그래프의 동작 원리 이해가 필요함.
• 자유도로 인한 혼란: MobX는 Redux보다 자유로운 방식으로 상태를 관리한다. 이는 프로젝트에서 일관된 패턴을 유지하기 어려울 수 있음.
• 커뮤니티의 크기: MobX의 사용자 커뮤니티는 Redux만큼 크지 않음.

---

 

🔔 마치며...

다양한 전역상태관리 라이브러리를 알아봤다. 직접 프로젝트에 적용해봐야 차이를 체감할 것 같다. 각각의 라이브러리들이 추구하는 방향성은 분명 차이가 있기 때문에 내 프로젝트가 큰 규모인가, 작은 단위로 분리가 필요한가, 빈번한 상태변경이 필요한가 등 요건들을 따져서 어떤 라이브러리를 사용해야할지 고려해야할 것 같다.

---

참고

https://docs.pmnd.rs/zustand/getting-started/introduction

Zustand Documentation

https://ko.redux.js.org/

Redux - 자바스크립트 앱을 위한 예측 가능한 상태 컨테이너. | Redux

https://mobx.js.org/react-integration.html

React integration · MobX 🇺🇦