[모던 리액트 Deep Dive] 5장

상태란 어떠한 의미를 지닌 값이며 애플리케이션의 시나리오에 따라 지속적으로 변경될 수 있는 값을 의미

웹 애플리케이션에서 상태로 분류될 수 있는 것들 ↓

- UI

- URL

- 폼

- 서버에서 가져온 값

 

tearing은 하나의 상태에 따라 서로 다른 결과물을 사용자에게 보여주는 현상을 말한다

 

Flux 패턴

양방향이 아닌 단방향으로 데이터 흐름을 변경하는 것

상태와 그 상태의 변경에 대한 흐름과 방식을 단방향으로 채택한 것이 특징

 

- 액션 : 어떤 작업을 처리할 액션과 그 액션 발생 시 함께 포함시킬 데이터를 의미

- 디스패처 : 액션을 스토어에 보내는 역할, 콜백 함수 형태로 타입과 데이터 모두 스토어에 보낸다

- 스토어 : 실제 상태에 따른 값과 상태를 변경할 수 있는 메서드를 가진다

- 뷰 : 스토어에서 만들어진 데이터를 가져와 화면을 렌더링 하는 역할을 한다

 

리덕스

Flux 구조를 구현하기 위한 라이브러리 중 하나인데 여기에 Elm 아키텍처 도입

 

Elm은 웹페이지를 선언적으로 작성하기 위한 언어

Elm 아키텍처의 핵심 ↓

- 모델(model) : 애플리케이션의 상태

- 뷰(view) : 모델을 표현하는 HTML

- 업데이터(update) : 모델을 수정하는 방식

 

Elm은 Flux와 마찬가지로 데이터 흐름을 세 가지로 분류하고 단방향으로 강제해 웹 애플리케이션의 상태를 안정적으로 관리하고자 했다

 

리덕스는 하나의 상태 객체를 스토어에 저장해 두고 이 객체를 업데이트하는 작업을 디스패치해 업데이트 수행

하나의 글로벌 상태 객체를 통해 하위 컴포넌트에 전파할 수 있어 prop 내려주기 문제를 해결할 수 있고 스토어가 필요한 컴포넌트라면 단지 connect만 쓰면 스토어에 바로 접근 가능

 

Context API

전역 상태를 하위 컴포넌트에 주입 가능

props로 상태를 넘겨주지 않더라도 원하는 곳에서 Context Provider 주입하는 상태 사용 가능

 

type Counter = {
  count: number
}

const CounterContext = createContext<Counter | undefined>(undefined)

class CounterComponent extends Component {
  render() {
    return (
      <CounterContext.Consumer>
        {(state) => <p>{state?.count}</p>}
      </CounterContext.Consumer>
    )
  }
}

class DummyParent extends Component {
  render() {
    return (
      <>
        <CounterComponent />
      </>
    )
  }
}

export default class MyApp extends Component<{}, Counter> {
  state = { count: 0 }
  
  componentDidMount() {
    this.setState({ count: 1 })
  }
  
  handleClick = () => {
   this.setState((state) => ({ count: state.count + 1 }))
 }
 
 render() {
   return (
     <CounterContext.Provider value={this.state}>
       <button onClick={this.handleClick}>+</button>
       <DummyParent />
     </CounterContext.Provider>
   )
 }
}

 

Context API는 상태 관리가 아닌 주입을 도와주는 기능이며, 렌더링을 막아주는 기능 또한 존재하지 않으니 주의 필요!

 

훅 API

state를 손쉽게 재사용 가능하도록 만들 수 있다

function useCounter() {
  const [count, setCount] = useState(0)
  
  function increase() {
    setCount((prev) => prev + 1)
  }
  
  return { count, increase }
}

 

React Query

외부에서 데이터를 불러오는 fetch를 관리하는 데 특화된 라이브러리

API 호출에 대한 상태를 관리하고 있기 때문에 HTTP 요청에 특화된 상태 관리 라이브러리

 

훅의 등장에 따라 훅을 활용해 상태를 가져오거나 관리할 수 있는 다양한 라이브러리 등장

Recoil, Jotai, Zustand, Valtio

기존의 리덕스와 다르게 훅을 활용해 작은 크기의 상태를 효율적으로 관리한다

개발자가 원하는 만큼의 상태를 지역적으로 관리하는 것을 가능하게 만들고 함수 컴포넌트에서 손쉽게 사용할 수 있다

 

 

---

 

useState

여러 컴포넌트에 걸쳐 손쉽게 동일한 인터페이스의 상태 생성, 관리 가능

function useCounter(initCount: number = 0) {
  const [counter, setCounter] = useState(initCount)
  
  function inc() {
    setCounter((prev) => prev + 1)
  }
  
  return { counter, inc }
}

 

useReducer

지역 상태를 관리할 수 있는 훅

첫 번째 인수로 reducer, 즉 state와 action을 어떻게 정의할지를 넘겨줘야 한다

type Initializer<T> = T extends any ? T | ((prev: T) => T) : never

function useStateWithUseReducer<T>(initialState: T) {
  const [state, dispatch] = useReducer(
    (prev: T, action: Initializer<T>) =>
      typeof action === 'function' ? action(prev) : action,
    initialState,
  )
  
  return [state, dispatch]
}

 

useState와 useReducer 모두 약간의 구현상의 차이만 있을 뿐 두 훅 모두 지역 상태 관리를 위해 만들어졌다

두 훅을 기반으로 하는 사용자 지정 훅의 한계는 훅을 사용할 때마다 컴포넌트별로 초기화되므로 컴포넌트에 따라 서로 다른 상태를 가질 수밖에 없다

기본적으로 useState를 기반으로 한 상태를 지역 상태라고 하고 이 지역 상태는 해당 컴포넌트 내에서만 유효하다는 한계가 있다

 

사용자의 상태를 사용자의 UI에 보여주기 위해서는 반드시 리렌더링이 필요하다

컴포넌트에서 리렌더링을 하려면 아래의 두 작업 중 하나가 일어나야 한다

- useState, useReducer의 반환값 중 두 번째 인수가 어떻게든 호출된다. 그것이 컴포넌트 렌더링과 관계없는 직접적인 상태를 관리하지 않아도 상관없고 어떤 방식으로든 두 번째 인수가 호출되면 리액트는 다시 컴포넌트를 렌더링 한다

- 부모 함수가 리렌더링 되거나 해당 함수가 다시 실행돼야 한다.

 

useState로 컴포넌트의 리렌더링을 실행해 최신값을 가져오는 방법은 해당 컴포넌트 자체에서만 유효한 전략

함수 외부에서 상태를 참조하고 이를 통해 렌더링까지 자연스럽게 일어나려면 ↓

 

1. 꼭 window나 global에 있어야 할 필요는 없지만 컴포넌트 외부 어딘가에 상태를 두고 여러 컴포넌트가 같이 쓸 수 있어야 한다

2. 외부에 있는 상태를 사용하는 컴포넌트는 상태 변화를 알아챌 수 있어야 하고 변화될 때마다 리렌더링이 일어나 컴포넌트를 최신 상태값 기준으로 렌더링해야 한다. 이 상태 감지는 상태를 변경시키는 컴포넌트뿐만 아니라 이 상태를 참조하는 모든 컴포넌트에 동일하게 작동해야 한다

3. 상태가 원시값이 아닌 객체인 경우 그 객체에 내가 감지하지 않는 값이 변하더라도 리렌더링이 발생해서는 안 된다

 

 

useStore와 useStoreSelector 훅을 사용하는 구조는 반드시 하나의 스토어만 가지게 된다

하나의 스토어를 가지면 이 스토어는 전역 변수처럼 작동해 동일한 현태의 여러 개의 스토어를 가질 수 없게 된다

훅을 사용하는 서로 다른 스코프에서 스토어의 구조는 동일하되, 여러 개의 서로 다른 데이터를 공유해 사용하고 싶다면 ↓

 

- createStore를 이용해 동일한 타입으로 스토어 여러 개 만들기

위 방법도 완벽하지 않고 해당 스토어가 필요할 때마다 반복적으로 생성해야 되기 때문에 번거롭다

 

- Context

Context로 해당 스토어를 하위 컴포넌트에 주입한다면 컴포넌트에서는 자신이 주입된 스토어에 대해서만 접근 가능

export const CounterStoreContext = createContext<Store<CounterStore>>(
  createStore<CounterStore>({ count: 0, text:'hello' }),
)

export const CounterStoreProvider = ({
  initialState,
  children,
}: PropsWithChildren<{
  initialState: CounterStore
}>) => {
  const storeRef = useRef<Store<CounterStore>>()
  
  if(!storeRef.current) {
    storeRef.current = createStore(initialState)
  }
  
  return (
    <CounterStoreContext.Provider value={storeRef.current}>
      {children}
    </CounterStoreContext.Provider>
  )
}

useRef를 사용했기 때문에 CounterStoreProvider는 오직 최초 렌더링에서만 스토어를 만들어서 값을 내려주게 된다

export const useCounterContextSelector = <State extends unknown>(
  selector: (state: CounterStore) => State,
) => {
  const store = useContext(CounterStoreContext)
  const subscription = useSubscription(
    useMemo(
      () => ({
        getCurrentValue: () => selector(store.get()),
        subscribe: store.subscribe,
      }),
      [store, selector],
    ),
  )
  
  return [subscription, store.set] as const
}

불필요한 반복을 제거하기 위해 기존에 리액트에서 제공하는 useSubscription 사용

스토어 접근을 위해 useContext 사용

즉, 스토어에서 값을 찾는 것이 아니라 Context.Provider에서 제공된 스토어를 찾게 만드는 것

 

 

useState, useReduer가 가지는 한계, 컴포넌트 내부에서만 사용할 수 있는 지역 상태라는 점을 극복하기 위해 외부 어딘가에 상태를 둔다. 이는 컴포넌트 최상단 내지는 상태가 필요한 부모가 될 수도 있고 혹은 격리된 자바스크립트 스코프 어딘가 일 수도 있다

외부의 상태 변경을 각자 방식으로 감지해 컴포넌트의 렌더링을 일으킨다

 

 

Recoil과 Jotai는 Context와 Provider, 훅을 기반으로 가능한 작은 상태를 효율적으로 관리하는 데 초점을 맞추고 있다

Zustand는 리덕스와 비슷하게 하나의 큰 스토어를 기반으로 상태를 관리하는 라이브러리로 Recoil, Jotai와 다르게 이 하나의 큰 스토어는 Context가 아니라 스토어가 가지는 클로저를 기반으로 생성되며 이 스토어의 상태가 변경되면 이 상태를 구독하고 있는 컴포넌트에 전파해 리렌더링을 알리는 방식

 

 

Recoil

훅의 개념으로 상태 관리를 시작한 최초의 라이브러리 중 하나

 

RecoilRoot

Recoil을 사용하기 위해서는 RecoilRoot를 애플리케이션의 최상단에 선언해야 한다

Recoil에서 생성되는 상태값을 저장하기 위한 스토어를 생성한다

export default function App() {
  return <RecoilRoot>{/* some components */}</RecoilRoot>
}

Recoil의 상태값은 RecoilRoot로 생성된 Context의 스토어에 저장된다

스토어의 상태값에 접근할 수 있는 함수들이 있으며 이 함수를 활용해 상태값에 접근하거나 상태값을 변경할 수 있다

값의 변경이 발생하면 이를 참조하고 있는 하위 컴포넌트에 모두 알린다

 

atom

상태를 나타내는 Recoil의 최소 상태 단위

type Statement = {
  name: string
  amount: number
}

const InitialStatements: Array<Statement> = [
  { name: '과자', amount: -500 },
  { name: '용돈', amount: 10000 },
  { name: '네이버페이충전', amount: -5000 },
]

const statementsAtom = atom<Array<Statement>>({
  key: 'statements',
  default: InitialStatements,
})

atom은 key를 필수로 가지며 다른 atom과 구별하는 식별자가 되는 필수 값

default는 atom의 초깃값

 

useRecoilValue

atom의 값을 읽어오는 훅

function Statements() {
  const statements = useRecoilValue(statementsAtom)
  return (
    <>{/* something */}</>
    
  )
}

 

useRecoilState

atom의 값을 가져오고 이 값을 변경할 수도 있는 훅

function useRecoilState<T>(
  recoilState: RecoilState<T>,
): [T, SetterOrUpdater<T>] {
  if (__DEV__) {
    validateRecoilValue(recoilState, 'useRecoilState')
  } 
  return [useRecoilValue(recoilState), useSetRecoilState(recoilState)]
}

 

 

Recoil은 추가적인 미들웨어 사용 없이 비동기 작업을 수월하게 처리할 수 있다

리액트와 비슷하게 자체적인 개발 도구를 지원해 Recoil을 기반으로 개발하는 데 많은 도움을 얻을 수 있다

 

 

Jotai

Recoil의 atom 모델에 영감을 받아 만들어진 상태 관리 라이브러리

상향식 접근법을 취하고 있어 리덕스와 같이 하나의 큰 상태를 애플리케이션에 내려주는 방식이 아니라 작은 단위의 상태를 위로 전파할 수 있는 구조를 취하고 있다

불필요한 리렌더링이 일어난다는 문제를 해결하고자 설계돼 있고 메모이제이션이나 최적화를 거치지 안 하고 리렌더링이 발생되지 않도록 설계돼 있다

 

atom

최소 단위의 상태를 의미

Recoil과 다르게 atom 하나만으로도 상태를 만들 수도 이에 파생된 상태까지 만들 수도 있다

key를 별도로 넘겨주지 않아도 된다

config라는 객체를 반환하는데 이 config는 초깃값을 의미하는 init, 값을 가져오는 read, 값을 설정하는 write만 존재

Jotai에서의 atom에 따로 상태를 저장하고 있지 않다

 

useAtomValue

useReducer에서 반환하는 상태값은 [version, valueFromReducer, atomFromReducer]

첫 번째는 store의 버전, 두 번째는 atom에서 get을 수행했을 때 반환되는 값, 세 번째는 atom 그 자체를 의미

 

useAtom

useState와 동일한 형태의 배열 반환

첫 번째로 현재 값을 나타내는 useAtomValue 훅의 결과 반환, 두 번째로는 useSetAtom 훅을 반환하는데 이 훅은 atom을 수정할 수 있는 기능 제공

 

Jotai는 atom의 개념을 도입하면서도 API가 간결하다

별도의 문자열 키가 없이도 각 값들을 관리할 수 있는 것은 객체의 참조를 통해 값을 관리하기 때문이다

selector가 없이도 atom만으로 atom 값에서 또 다른 파생된 상태를 만들 수 있다

 

 

Zustand

리덕스에 영감을 받아 만들어졌는데 하나의 스토어를 중앙 집중형으로 활용해 이 스토어 내부에서 상태를 관리하고 있다

 

import { create } from 'zustand'

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

function Counter() {
  const { count, inc, dec } = useCounterStore()
  return (
    <div class="counter">
      <span>{count}</span>
      <button onClick={inc}>up</button>
      <button onClick={dec}>down</button>
    </div>
  )
}

 

 Zustand는 특별히 많은 코드를 작성하지 않아도 빠르게 스토어를 만들고 사용할 수 있다

간단하고 빠르게 상태를 정의할 수 있어 상태를 관리하는 입장에서 한결 가볍고 편리하다

API가 복잡하지 않고 사용이 간단해 쉽게 접근할 수 있는 라이브러리로 손꼽을 수 있다

리덕스와 마찬가지로 미들웨어를 지원한다

create의 두 번째 인수로 원하는 미들웨어를 추가하면 되는데 persist, immer 등 여러 미들웨어를 제공해 필요한 미들웨어를 사용할 수 있게 도와준다

 

 

각 상태 관리 라이브러리가 상태를 관리하는 방식에는 조금씩 차이가 있지만 리액트에서 리렌더링을 일으키기 위한 방식은 제한적이기 때문에 어떤 방식으로  상태를 관리하든지 리렌더링을 만드는 방법은 모두 거의 동일하다

npm에서 제공하는 라이브러리와 마찬가지로 메인테이너가 많고 다운로드가 활발하며 이슈가 관리가 잘되고 있는 라이브러리를 선택하는 게 좋다