상태란?
주어진 시간에 대해 시스템을 나타내는 것으로 언제든지 변경될 수 있음.
문자열, 배열, 객체 등의 형태로 응용 프로그램에 저장된 데이터!
→ 개발자 입장에선 관리해야하는 데이터들
모던 웹 프론트엔드는 프로덕트가 커져서 관리해야할 상태도 많아졌음.
너무 많은 레포.
반복되는 컴포넌트, 로직..
Redux로 구성한 Store 코드인데, 상태관리보단 API 통신 코드같다.
(이때는 rtk 같은 게 없었다고 함)
소유주가 Client냐 Server냐에 따라 상태를 두 가지로 나누어 보자.
Client State. Server State.
소유주가 Client냐 Server냐에 따라.
배민 주문팀에서는 React Query 기술을 채택했다.
fetching, caching, synchronizing and updating server state.
zero-config, can be customized.
로 감싸고 있음.
컨텍스트와 비슷한데?
사용은 useQuery
세가지 core 컨셉
Queries. Mutations. Query Invalidation.
데이터 Fetching 용!
userQuery(’todos’, fetchTodoList, option) // query key, query function, option
qeury keyDP 따라 query caching을 관리.
string과 array형태로 사용할 수 있음.
queries 파일 분리 추천!
redux에서 언제 server state를 받을까? → onSuccess단계가 좋다고 생각한다.
데이터 생성/수정/삭제용!
useMutation(mutationFn,
onMutate는 Optimistic update를 적용할 때 유용
api 요청을 성공할 것이라고 보고 UI 업데이트. 롤백 가능.
queryClient.invaldateQueries()
query가 stale 취급 된다.
RFC 5861
stale-while-revalidate
→ 백그라운드에서 stale response를 revalidate 하는 동안 캐시가 가진 stale response를 반환
Cache-Control: max-age=600, stale-while-revalidate=30
600초 동안은 유효한 값이라고 생각한다.
latency가 숨겨짐.
새 물건이 올 때까지 옛날 물건을 보여준다.
( 이 부분은 조금 더 공부 후에 채워 놔야겠다. )
이 컨셉을 메모리 캐시에도 적용해보자!
cacheTime: 메모리에 얼마만큼 있을건지
staleTime: 얼마의 시간이 흐른 후에 데이터를 stale 취급할 건지.
Query 상태흐름
fetching → fresh → stale → inactive → deleted
스크린에서 빠져나갈때 stale→inactive
다시 mount되어도 fresh한 값이면 refetch가 일어나지 않음.
전역으로 관리될까?
중복호출 될까?
답은 Context API에 있다.
내부적으로 컨텍스트를 이용함!
Store는 Client State만 남았다!
Server State는 React Query와 함꼐 좋아졌다!
Component는 쬐끔 길어졌지만 수용가능한 범위.
다른 상태관리라이브러리들보다 직관적이다!
Component가 상대적으로 비대해지는 문제
좀 더 난이도가 높아진 프로젝트 설계
단순 API 통신 이상으로 장점을 잘 활용할 방법
역시 중요한건 트렌드보단 Why!
추가 질문
swr과 다른점?
리액트 쿼리가 더 많은 인터페이스를 제공함.
Client 스토어?
Mobx
query 키?
함수명으로 자주 씀
디폴트 옵션?
안씀
에러바운더리?
안씀! Suspense는 실험단계라서 안씀!
시간 날 때 내용 수정 및 추가 해야겠다...