🐻 Context API와 Provider 지옥과 귀여운 곰돌이 🐻

Zustand를 도입한 이유

WebRTC 기능을 구현할 때 관리할 상태가 많아졌다. 매우 많이!!
그래서 Props Drilling 문제가 발생했고, 전역상태의 도입이 필요했다.

처음에는 Context API로 이를 해결해보려 시도했다.
하지만 도중에 사용성이 좋지 못하다고 판단했고, Zustand를 사용하기로 결정했다.

WebRTC 관련 상태가 많아지고 복잡해졌다

처음에는 UI에 관련된 상태만 생각했다. 그래서 전역 상태 관리에 대해 생각을 하지 못했다.
그런데 WebRTC 기능을 구현 하다보니 처음에 예상했던것보다 관리할 상태가 많아졌다...😨

그래서 일단 WebRTC 기능을 담당하는 useWebRTC 훅에 이 상태를 전부 넣어줬다.
지금 생각해보면 그건 매우 크나큰 실수였다... 아마 거기부터 모든게 잘못됐던것 같다.

위의 코드만 봐도 벌써 상태가 많은데 앞으로 기능을 추가하면 더 늘어날 예정이다.

Context API 리렌더링 이슈

흔히 Context API를 사용하면 리렌더링 이슈가 존재한다고 하고 이를 최적화 해야한다고 한다.
근데 이걸 사용하면서 나는 내용을 학습하고 정리하기 전까지도 정확히 이유를 몰랐다!!!
그래서 이걸 최적화 하려고 했는데 코드가 길어지고 코드 중복이 많아졌기에 전역 상태 관리 라이브러리를 찾아보게 되었다.

리렌더링이 일어나는 이유

NameAgeProvider 아래에 <Name/> 과 <Age/> 가 있는 상황을 한번 가정해본다.
만약 <Name/> 에서 상태변경을 일으키면 <Name/>은 리렌더링 되는게 머리에 그려진다.
근데 <Age/> 도 리렌더링이 발생한다.

왜냐하면 리액트는 Provider 안의 상태가 변경 되었을 때 useContext로
그 상태를 사용하고 있는 모든 컴포넌트를 리렌더링 시켜버리기 때문이다.

그래서 Context API를 사용하면 반드시 Provider를 최대한 작게 쪼개야한다.

Provider 분리

위 사진은 기존 NameAgeProvder를 NameProvider와 AgeProvider로 분리시킨 모습이다.
만약 이렇게 하면 두개의 컴포넌트는 서로 다른 Context를 참조하므로 상태가 바뀌어도 리렌더링이 일어나지 않는다.

Provider 지옥

그런데 이렇게 Provider를 작개 쪼개면 Provider 지옥이 펼쳐진다.
처음에는 리렌더링 되는 컴포넌트를 관리하기 쉽겠지만 컴포넌트의 수가 늘수록 기하급수적으로 어려워질것이다.

Context API를 포기한 첫번째 이유다.

SetStateAction 함수 관리를 위한 훅

추가적으로 상태를 바꾸는 함수들도 관리 해 주어야 한다.
이는 곧 보일러플레이트 코드 수가 늘어난다는 뜻과 같다.

그리 길지는 않지만 맨 윗부분에 Provider 안에 있는지 확인하는 과정을 반드시 거쳐야 할 것이고
Provider 개수만큼 이를 관리해주는 훅의 개수도 늘어날 것이다.

Context API를 포기한 두번째 이유다.

전역 상태 관리 라이브러리 후보

Redux, Recoil, Zustand 이렇게 세가지 정도를 고민했다.
Redux는 가장 유명한 라이브러리이니 말할 필요도 없고 Recoil은 편리성이 높기에 같이 고민했다.
그리고 Zustand는 Recoil과 다르게 안정적인 버전이 존재하고 Recoil만큼 사용하기 편하다기에 고민했다.

승자는!!

세가지 후보중 승자는 Zustand다.
우선 이유는 곰돌이가 귀엽기 때문이다.
그리고 귀엽기 때문이다.

진짜이유

제일 컸던 이유는 곰돌이가 귀여웠기 때문이다.
원래 Recoil을 도입하려 했는데 곰돌이를 보고 마음이 바뀌었다.

러닝커브가 낮다.

러닝커브가 매우 낮았다. 아래 코드는 공식문서의 코드인데 정말 짧고 이해하기 쉽다.
빠른 도입이 필요했기에 낮은 러닝커브는 정말 중요했다.
이정도면 프론트엔드를 모르는 백엔드 개발자가 봐도 쉬울거라 생각한다.

import { create } from 'zustand'

const useStore = create((set) => ({
  count: 1,
  inc: () => set((state) => ({ count: state.count + 1 })),
}))

function Counter() {
  const { count, inc } = useStore()
  return (
    <div>
      <span>{count}</span>
      <button onClick={inc}>one up</button>
    </div>
  )
}

액션함수도 함께 관리.

위의 코드를 보면 inc 라는 함수를 create 함수 안에서 함께 생성하고 있다.
Redux도 위와 비슷하지만 조금 더 복잡하고, recoil은 전혀 그러지 않는다.
그리고 Context API도 따로 훅으로 관리 해줘야 했다.

키 관리 여부

Recoil의 경우 key로 atom을 구분한다. 그래서 key가 중복되면 안되고 관리를 해 줘야한다.
근데 Zustand는 그런 부분도 없다.

낮은 용량

직접 비교 해봐도 1.1kB로 제일 낮은걸 확인할 수 있다.