
웹 애플리케이션에서의 상태
- UI
- 상호 작용이 가능한 모든 요소의 현재 값
- 다크/라이트 모드, 라디오를 비롯한 각종 input, 알림창의 노출 여부 등
- URL
- 브라우저에서 관리되고 있는 상태 값
- form
- 로딩 중인지, 현재 제출됐는지, 접근이 불가능한지, 값이 유효한지 모두 상태로관리
- 서버에서 가져온 값
- 클라이언트에서 서버로 요청을 통해 가져온 값
- API 요청
상태 관리가 왜 필요한지
- 애플리케이션 전체적으로 간리해야 할 상태가 있을 때
- 상태를 어디에 둘 것인지(전역 변수 혹은 별도의 클로저)
- 상태가 유효한 범위는 어떻게 제한할지
- 상태의 변화에 따라 변경돼야 하는 자식 요소들은 어떻게 이 상태의 변화를 감지할 것인지ㅏ
- 상태 변화가 일어남에 따라 즉각적으로 모든 요소들이 변경되어 애플리케이션이 찢어지는 현상을 어떻게 방지할지
리액트 상태 관리의 역사
- Flux 패턴의 등장
- Redux의 등장
- Context API와 useContext
- 훅의 탄생, React Query, SWR
- 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 요청에 대해서만 쓸 수 있기 때문에 좀 더 범용적으로 쓸 수 있는 상태 관리 라이브러리를 찾음
- 훅을 활용해 작은 크기의 상태를 효율적으로 관리할 수 있음
'FE > 리뷰' 카테고리의 다른 글
[모던 리액트 딥다이브] 6장 리액트 개발 도구 (0) | 2024.08.17 |
---|---|
[모던 리액트 딥다이브] 5.2장 리액트 훅으로 시작하는 상태 관리 (0) | 2024.08.11 |
[모던 리액트 딥다이브] 4.3장 Next.js (1) | 2024.08.04 |
[모던 리액트 딥다이브] 4.2장 SSR을 위한 리액트 API (0) | 2024.08.03 |
[모던 리액트 딥다이브] 4.1장 서버 사이드 렌더링 (0) | 2024.07.21 |

웹 애플리케이션에서의 상태
- UI
- 상호 작용이 가능한 모든 요소의 현재 값
- 다크/라이트 모드, 라디오를 비롯한 각종 input, 알림창의 노출 여부 등
- URL
- 브라우저에서 관리되고 있는 상태 값
- form
- 로딩 중인지, 현재 제출됐는지, 접근이 불가능한지, 값이 유효한지 모두 상태로관리
- 서버에서 가져온 값
- 클라이언트에서 서버로 요청을 통해 가져온 값
- API 요청
상태 관리가 왜 필요한지
- 애플리케이션 전체적으로 간리해야 할 상태가 있을 때
- 상태를 어디에 둘 것인지(전역 변수 혹은 별도의 클로저)
- 상태가 유효한 범위는 어떻게 제한할지
- 상태의 변화에 따라 변경돼야 하는 자식 요소들은 어떻게 이 상태의 변화를 감지할 것인지ㅏ
- 상태 변화가 일어남에 따라 즉각적으로 모든 요소들이 변경되어 애플리케이션이 찢어지는 현상을 어떻게 방지할지
리액트 상태 관리의 역사
- Flux 패턴의 등장
- Redux의 등장
- Context API와 useContext
- 훅의 탄생, React Query, SWR
- 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 요청에 대해서만 쓸 수 있기 때문에 좀 더 범용적으로 쓸 수 있는 상태 관리 라이브러리를 찾음
- 훅을 활용해 작은 크기의 상태를 효율적으로 관리할 수 있음
'FE > 리뷰' 카테고리의 다른 글
[모던 리액트 딥다이브] 6장 리액트 개발 도구 (0) | 2024.08.17 |
---|---|
[모던 리액트 딥다이브] 5.2장 리액트 훅으로 시작하는 상태 관리 (0) | 2024.08.11 |
[모던 리액트 딥다이브] 4.3장 Next.js (1) | 2024.08.04 |
[모던 리액트 딥다이브] 4.2장 SSR을 위한 리액트 API (0) | 2024.08.03 |
[모던 리액트 딥다이브] 4.1장 서버 사이드 렌더링 (0) | 2024.07.21 |