8월 16일 - 3차

1. 리덕스

• 리덕스는 자바스크립트를 위한 라이브러리

• 리액트에서만 사용하는 것은 아니다!

• 리액트에서 사용할 수 있도록 감싸주는 기능은 react-redux에서 제공하는 것

• 자바스크립트 앱이 고도화 => 복잡해지는 데이터 통제를 위해 고안된 것

• 상태변화를 관리하기 위해 상태 변화를 일으키는 시점과 형태에 제약을 둠
• 1) 데이터 변경은 Action 에 의해 순수함수인 Reducer 내에서 발생
• 2) 단방향 : ((view -> action+ dispatcher -> middleware -> reducer -> sotre) -> view

• View에서 유저가 일으키는 행동에 맞게 Action 객체가 생성되고,
• Action은 Dispatcher를 통해 Reducer로 전달되고,
• Action의 type에 따라 Reducer 내에 미리 정해져 있던 로직이 Store를 변경하고,
• 변경된 Store의 내용이 View로 반영되는 패턴

2. 왜 리덕스를 사용하는가?

• 전역 상태 관리
  • 여러 컴포넌트에 걸쳐 있는 변화
  • 멀리 떨어진 컴포넌트 간의 통신
• Props Drilling을 피하기 위해
  • React는 state, props가 변화할 경우 해당 컴포넌트를 re-render
  • props를 통해 여러 번 전달되는 데이터가 전달 되는 경우 실제 변화가 적용되어야 하는 컴포넌트 뿐만 아니라, 전달 경로에 있는 컴포넌트들도 re-render

3. 사용하기

useSelector hook은 내부적으로 Context API를 사용하여, 전역 상태와 Consumer 컴포넌트가 1:1 관계를 맺고 통신 가능

import { Provider } from 'react-redux'
import store from './store'
import App from './App'

const root = ReactDOM.createRoot(document.getElementById('root'))
root.render(
  <Provider store={store}>
    <App />
  </Provider>
)

export function Counter() {
  const count = useSelector(selectCount)
  const dispatch = useDispatch()
	// ...
}

4. 문제점

• redux는 복잡한 상태를 Store에 저장 + 비동기 처리 redux-thunk 와 redux-saga 와 같은 미들웨어 함수로 사용
• 하지만
  1) 보일러 플레이트 코드가 많다 => redux-toolkit
  2) redux store에 저장하는 것이 진실한 정보의 원천(Single source of truth) 에 부합하는가???
  => store에 저장하는 것은 사본일 뿐 ⬇️ 캐시를 다루는 것과 비슷하네?

stale-while-revalidate 전략 (react-query, SWR)
1) 캐시된 응답이 오래될 수 있다고 가정하는 부분
2) 그 캐시된 응답을 재검증하는 프로세스 부분

Cache-Control: max-age=1, stale-while-revalidate=59

• 1) Cache-Control Header의 max-age를 확인
  • 아직 만료되지 않았으면 → Do nothing
• 2) 만료되었으면 stale-while-revalidate 값을 확인
  • stale-while-revalidate 값을 넘지 않았다면
    • 일단 캐싱된 값을 반환
    • 동시에 향후 사용을 위해 데이터를 요청하여 최신화
  • 넘었다면
    • 데이터를 새로 요청해서 최신화

5. react-query

yarn add @tanstack/react-query

(TanStack Query)

클라이언트에서 가지고 있는 정보와 서버의 정보가 동일한지(active), 혹은 다른지(stale)를 중심으로 상태를 캐시의 관점에서 재정의해볼 수 있을 것 같습니다.

• Fetching: 서버에서 데이터를 가져오는 동안 갖게 되는 상태
• Fresh: 이 상태에서는 서버 / 클라이언트의 정보가 동일하다는 것이 보장
  하지만 서버로부터 가져온 데이터가 최신인지는 거의 대부분의 경우에 보장하기 어렵다.
  React Query에서는 active에서 stale 상태로 넘기는 옵션인 staleTime 의 기본 값을 0(즉시)으로 설정
• Stale: 서버 / 클라이언트의 정보가 동일함을 보장할 수 없는(신선하지 않은) 상태
  서버로부터 새로운 값을 업데이트 받지 않았거나, 클라이언트에서 입력 받은 값을 서버에 전송하지 않은 경우 stale하다고 할 수 있다. 이 경우 React Query는 값을 업데이트 하기 위해 새 요청을 보낸다
• Inactive: 해당 쿼리가 React Query 가비지 컬렉터에 의해 제거될 될 예정임을 알란다. 사용되지 않는 쿼리(ex. umount)는 inactive 처리 된다
• Deleted: 삭제된 쿼리

서버 상태(Server State) : 클라이언트는 마치 브라우저 캐시처럼 앱 내에 API 호출에 대한 별도의 저장소를 가지고, 해당 데이터들의 호출 정보와 위에 소개드린 다섯 가지 상태 여부를 체크하는 방식으로 비동기 호출을 관리하고 이 정보를 서버 상태라고 부른다

React Query는 이 과정을 자동화하면서 DX(Developer Experience)를 극대화 했다는 점에서 커다란 차별점

=> 개발자는 UI 상태에만 집중할 수 있다 => 비동기 처리를 위한 thunk, saga 같은 미들웨어 라이브러리도 불필요

Docs

이름이 바뀌었다???????

• 주의할 것

  처음 react-query를 사용할 때 Network 탭에 너무 많은 요청이 일어난다고 생각할 수 있음
  => 서버 상태와 클라이언트 상태가 동기화 되는 과정

  옵션 선택에 따라 달라짐.

• refetchOnMount **: useQuery를 포함한 컴포넌트가 Mount 될 때마다 revalidate
• refetchOnWindowFocus : 브라우저가 포커스를 얻을 때마다 revalidate
• refetchOnReconnect : 네트워크가 끊어졌다가 다시 연결될 때마다 revalidate
• 개발자가 직접 Mutation 등의 작업 이후 queryClient.invalidateQueries 를 사용해 수동으로 쿼리를 무효화 하여 revalidate

3회차 회고

아무래도 '챌린지'다 보니까 , 내가 생각했던 방향과는 다른 것 같다.
리액트 쿼리에 대해 배우고 적용하는 2주짜리 프로그램인 줄 알았는데 방향성이 조금 다른 듯한.
리액트 쿼리에 대한 지식이 있는 상태에서 과제를 수행해야하는 것 같은데, 나는 리액트 쿼리에 대한 기초부터 같이 해보는 건줄 알았던 ... ㅎㅎㅎ 아무래도.. 리액트 쿼리에 대한 공부를 천천히 다시 하고, 수업 내용을 다시 훑어 봐야할 것 같다... 과제를 다시 해보면서 연습해봐야 할 것 같다 ^^;; 9월에 리액트 쿼리 다시 공부해야지...