[모던 리액트 딥다이브] 5.1장 상태 관리

웹 애플리케이션에서의 상태

• UI
  • 상호 작용이 가능한 모든 요소의 현재 값
  • 다크/라이트 모드, 라디오를 비롯한 각종 input, 알림창의 노출 여부 등
• URL
  • 브라우저에서 관리되고 있는 상태 값
• form
  • 로딩 중인지, 현재 제출됐는지, 접근이 불가능한지, 값이 유효한지 모두 상태로관리
• 서버에서 가져온 값
  • 클라이언트에서 서버로 요청을 통해 가져온 값
  • API 요청

 

 

상태 관리가 왜 필요한지

• 애플리케이션 전체적으로 간리해야 할 상태가 있을 때
  • 상태를 어디에 둘 것인지(전역 변수 혹은 별도의 클로저)
  • 상태가 유효한 범위는 어떻게 제한할지
  • 상태의 변화에 따라 변경돼야 하는 자식 요소들은 어떻게 이 상태의 변화를 감지할 것인지ㅏ
  • 상태 변화가 일어남에 따라 즉각적으로 모든 요소들이 변경되어 애플리케이션이 찢어지는 현상을 어떻게 방지할지

 

리액트 상태 관리의 역사

1. Flux 패턴의 등장
2. Redux의 등장
3. Context API와 useContext
4. 훅의 탄생, React Query, SWR
5. Recoil, Zustand, Jotai, Valtio..

 

 

Flux 패턴

• 웹 애플리케이션이 비대해지고 상태도 많아짐에 따라 어디서 어떤 일이 일어나는지 추적하고 이해하기 어려움
• 문제의 원인을 양방향 데이터 바인딩으로 봄
• Flux 패턴은 단방향으로 데이터 흐름을 변경하는 것을 제안
• 사용자의 입력에 따라 데이터를 갱신하고 화면을 어떻게 업데이트해야 하는지도 코드로 작성해야 하므로 코드의 양이 많아지고 개발자고 수고로워짐
• 하지만 데이터의 흐름을 추적하기 쉽고 코드를 이해하기 한결 쉬움
• Action => Dispatcher => Store => View
• Action
  • 어떠한 작업을 처리할 액션과 그 액션 발생 시 함께 포함시킬 데이터를 의미
  • 액션 타입과 데이터를 각각 정의해 이를 디스패터로 보냄
• Dispatcher
  • 액션을 스토어에 보내는 역할
  • 콜백 함수 형태로 앞서 액션이 정의한 타입과 데이터를 모두 스토어에 보냄
• Store
  • 여기에서 실제 상태에 따른 값과 상태를 변경할 수 있는 메서드를 가짐
  • 액션의 타입에 따라 어떻게 이를 변경할지 정의됨
• View
  • 리액트의 컴포넌트에 해당하는 부분
  • 스토어에서 만들어진 데이터를 가져와 화면을 렌더링하는 역할
  • 뷰에서도 사용자의 입력이나 행위에 따라 상태를 업데이트할 때 뷰에서 액션을 호출할 수 있음

 

 

 

 

Redux

• Flux 구조를 구현하기 위해 만들어진 라이브러리
• 추가적으로 Elm 아키텍처를 도입함
• 하나의 상태 객체를 스토어에 저장해 두고, 이 객체를 업데이트하는 작업을 디스패치해 업데이트를 수행함
• 이 작업은 reducer 함수로 발생시킬 수 있는데, 이 함수의 실행은 웹 애플리케이션 상태에 대한 완전히 새로운 복사본을 반환한 다음, 애플리케이션에 이 새롭게 만들어진 상태를 전차하게 됨
• 리덕스가 등장하며 하나의 글로벌 상태 객체를 통해 이 상태를 하위 컴포넌트에 전파할 수 있게 되고, 스토어가 필요한 컴포넌트라면 단지 connect만 쓰면 스토어에 바로 접근할 수 있게 됨
• 하지만, 단순히 하나의 상태를 바꾸고 싶어도 어떤 액션인지 타입을 선언하고, 액션을 수행할 creater, dispatcher, selector도 필요하고, 새로운 상태가 어떻게 기존의 리듀서 내부에서 어떤 식으로 변경돼야 할지, 새로 만들어야 할지도 매번 정의해야 함 => 하는 일에 비해 보일러플레이트가 많음

 

Elm : 웹페이지를 선언적으로 작성하기 위한 언어
모델 : 애플리케이션의 상태
뷰 : 모델을 표현하는 HTML
업데이트 : 모델을 수정하는 방식

 

 

 

Context API와 useContext

• 리액트의 props drilling 문제를 해결하기 위해 전역 상태를 하위 컴포넌트에 주입할 수 있는 Context API가 출시됨
• props로 상태를 넘겨주지 않더라도 Context API를 사용하면 원하는 곳에서 Context Provider가 주입하는 상태를 사용할 수 잇음
• 하지만, 상태 관리가 아닌 주입을 도와주는 기능이기 때문에 렌더링을 막아주지 않아 사용할 때 주의가 필요함

 

 

React Query와 SWR

• 외부에서 데이터를 불러오는 fetch를 관리하는 데 특화된 라이브러리
• API 호출에 대한 상태를 관리하기 때문에 HTTP 요청에 특화된 상태 관리 라이브러리

import React from 'react'
import useSWR from 'swr'

const fetcher = (url) => fetch(url).then((res) => res.json())

const App = () => {
    const {data, error} = useSWR(url, fetcher)

    if(error) return 'An error has occurred'
    if(!data) return 'Loading...'
  return (
    <div>{JSON.stringify(data)}</div>
  )
}

export default App

 

• useSWR의 첫 번째 인수로 조외할 API 주소를, 두 번째 인수로 조회에 사용되는 fetch를 넘겨줌
• 첫 번째 인수인 API 주소는 키로도 사용, 이후에 다른 곳에서 동일한 키로 호출하면 재조회하는 것이 아니라 useSWR이 관리하고 있는 캐시의 값을 활용함

 

SWR(Stale-While-Revalidate)
- vercel에서 개발한 상태 관리 라이브러리
- 데이터 요청 시, 먼저 캐시에 저장된 (stale) 데이터를 즉시 반환
- 그 후, 백그라운드에서 새로운 데이터를 가져와 (revalidate) 캐시를 업데이트하고 UI를 갱신

React Query vs SWR
- React Query는 데이터 패칭, 캐싱, 동기화, 백그라운드 업데이트 등 복잡한 상태 관리를 위한 더 많은 기능 제공
- 추가적으로 데이터 무효화, 수동리패치, pagination, infinite scrolling 과 같은 고급 기ㅡㅇ 내장함
- mutation도 지원
- SWR는 주로 데이터 패칭과 캐싱에 집중된 경량 라이브러리
- 간단하고 직관적인 API 제공, Mutation을 직접적으로 다루진 않음

 

 

 

전역 상태 관리 라이브러리(Recoil, Zustand, Jotai, Valtio)

• SWR, React Query가 HTTP 요청에 대해서만 쓸 수 있기 때문에 좀 더 범용적으로 쓸 수 있는 상태 관리 라이브러리를 찾음
• 훅을 활용해 작은 크기의 상태를 효율적으로 관리할 수 있음