🤪 나만 몰랐던 Zustand

항상 나는 상태관리 라이브러리 중에는 zustand가 가장 편하다고 생각했었다. 장점밖에 없는 라이브러리인데 왜 리덕스랑 차이가 있는걸까? 라고 생각하려던 찰나 내가 알고 있던 zustand는 그냥 아무것도 아니였다는 것을 알게되었다.
그동안 정말 가벼운 전역상태를 관리하고 있었는데 최근 프로젝트에서 상태관리를 deep하게 사용하게 되는 경우가 생겼다.

Provider

provider 그까이꺼 필요는 해?

🫢 한 화면에 동일한 종류의 컴포넌트 여러 개가 동시에 렌더링되고, 각각 독립적인 상태를 유지해야 할 때 (예: 여러 개의 동일한 위젯, 여러 개의 동시 편집 창)가 Provider를 사용하여 독립적인 스토어 인스턴스를 제공하고 상태를 격리해야 한다. 이런 경우 글톤 스토어를 사용한다면 데이터를 독립적으로 사용하지 못하고, 비효율적인 코드가 되는 것이다.

이 Provier가 존재하지 않는다는 점이 Zustand의 장점이자 최대 단점인 것 같다. 그래서 간단한 프로젝트에서는 zustand가 훨씬 유리하고, 간편하다고 느끼는 것이고, redux 같은 경우는 비교적 복잡하고 각각의 독립적인 상태관리를 해야 하는 경우 더 적합하다고 느껴지는 것 같다.

아직 jotai나 recoil은 사용해본적이 없어서 아쉽다 ㅠ

그렇다면 가장 중요한 부분 ~~ ☝️
과연 zustand에서는 Provider를 전혀 사용할 수가 없을까?
아직 zustand에서 직접적으로 Provider를 제공해주고 있지는 않지만 리액트의 context와 함께 쓴다면 가능 하다!!!

import React, { createContext, useContext, useState } from 'react';
import { useStore } from 'zustand';
import { createStore } from 'zustand/vanilla';

// 1. 스토어 생성 로직 정의 (Provider 내에서 직접 사용)
//    (예시: 간단한 카운터 스토어)
const createCounterStore = () => createStore((set) => ({
  count: 0,
  increment: () => set((state) => ({ count: state.count + 1 })),
  decrement: () => set((state) => ({ count: state.count - 1 })),
}));

// 2. React Context 생성
//    타입스크립트를 사용한다면 ReturnType<typeof createCounterStore> | null 로 타입 지정
const StoreContext = createContext(null);

// 3. Provider 컴포넌트
export const CounterStoreProvider = ({ children }) => {
  // useState의 초기값 함수를 사용하면 컴포넌트가 처음 마운트될 때
  // createCounterStore()가 딱 한 번만 호출되어 스토어 인스턴스를 생성하고 상태로 저장합니다.
  const [store] = useState(() => createCounterStore());

  // 생성된 스토어 인스턴스를 Context Provider의 value로 전달
  return (
    <StoreContext.Provider value={store}>
      {children}
    </StoreContext.Provider>
  );
};

// 4. Context를 사용하는 커스텀 훅
export const useCounterStore = (selector) => {
  // useContext로 Provider가 제공한 스토어 인스턴스를 가져옵니다.
  const store = useContext(StoreContext);
  if (!store) {
    // Provider로 감싸져 있지 않으면 에러 발생
    throw new Error('Cannot find CounterStoreProvider. Make sure to wrap the component tree.');
  }
  // Zustand의 useStore 훅에 Context로부터 얻은 스토어와 selector를 전달합니다.
  return useStore(store, selector);
};

// --- 사용 예시 ---

// Counter 컴포넌트 (상태 사용)
function CounterDisplay() {
  // 커스텀 훅을 통해 상태 값 접근
  const count = useCounterStore((state) => state.count);
  return <span>Count is: {count}</span>;
}

// Controls 컴포넌트 (상태 변경 함수 사용)
function CounterControls() {
  // 커스텀 훅을 통해 상태 변경 함수 접근
  const increment = useCounterStore((state) => state.increment);
  const decrement = useCounterStore((state) => state.decrement);
  return (
    <div>
      <button onClick={increment}>+</button>
      <button onClick={decrement}>-</button>
    </div>
  );
}

// App 컴포넌트 (Provider로 감싸기)
export default function App() {
  return (
    <div>
      <h2>Counter 1 (Independent)</h2>
      {/* Provider로 감싸주면 이 하위 컴포넌트들은 첫 번째 스토어 인스턴스를 사용 */}
      <CounterStoreProvider>
        <CounterDisplay />
        <CounterControls />
      </CounterStoreProvider>

      <hr />

      <h2>Counter 2 (Independent)</h2>
      {/* 새로운 Provider는 새로운 스토어 인스턴스를 생성하고 사용 */}
      <CounterStoreProvider>
        <CounterDisplay />
        <CounterControls />
        {/* 이 Provider 안에 또 다른 CounterDisplay를 넣어도 동일한 스토어 공유 */}
        <CounterDisplay />
      </CounterStoreProvider>
    </div>
  );
}

대충봐도 상당히 복잡하긴 하지만, 그래도 막상 사용을 해보면 아주 복잡하지만은 않다. 이런식으로 zustand를 상황에 맞춰 사용을 한다면 간단하게 사용하면서도, 독립적인 상태관리를 구현 할 수 있는 아주 좋은 라이브러리이다.

🥘 useShallow

Zustand에서 useShallow(또는 shallow 함수)를 사용하는 가장 큰 이유는 상태가 업데이트되었을 때, 얕은(shallow) 비교로 불필요한 리렌더링을 막아서 성능을 최적화할 수 있는 기능이다.
보통 Zustand로 상태를 가져올 때,

const { increase, decrease } = useCountStore(
  useShallow((state) => ({
    increase: state.increase,
    decrease: state.decrease,
  }))
)ㅁ

이런 식으로 마지막에 shallow 또는 useShallow 같은 걸 붙이면, 이전에 내가 구독한 값들이랑 새로 구독한 값들이 얕은 비교(===)로 바뀌었는지 안 바뀌었는지를 체크바뀌지 않았다면 해당 React 컴포넌트를 리렌더링하지 않음.

즉, 여러 개의 상태를 한꺼번에 가져와도 실제로는 전부 객체/배열 레퍼런스가 바뀌지 않았다면 리렌더링을 건너뛰게되어, 사용자 입장에서 더 부드러운 성능을 얻을 수 있다는 것이다.

정리하자면, useShallow는 Zustand 스토어에서 상태 여러 개를 동시에 구독할 때, 이 값들이 얕은 비교로 변하지 않았다면 리렌더를 안 하겠다는 로직을 적용하기 위한 비교 함수를 제공해주는 것이다.