📍참고 https://redux-toolkit.js.org/rtk-query/usage/automated-refetching#definitions Automated Re-fetching | Redux Toolkit RTK Query > Usage > Automated Refetching: cache invalidation management redux-toolkit.js.org 📍Tags 정의 - re-fetching 목적으로 캐싱 및 무효화 동작을 제어하기 위해 특정 데이터 집합에 붙이는 이름 - 데이터가 mutation의 영향을 받을지 여부를 결정하기 위해 붙이는 label 개념 생성 시점 - createApi를 호출할 때 tagTypes 프로퍼티에 정의할 수 있다 - 예) createApi({ //..

📍store 객체를 확인해보고 싶을 때 1️⃣/store/index.ts 에서 마지막에 window.store = store 해서 전역에서 store에 접근할 수 있게 바인딩 2️⃣그리고 크롬 콘솔창에서 store.getState() 실행하면 store 객체 확인 가능 - queries - mutations 등 프로퍼티 존재 fetch 실행하는 컴포넌트 렌더링 후 store.getState() 실행하면 query 이름과 데이터 자세히 확인 가능 📍이는 Redux Devtools 로도 확인 가능!!

📍참고 https://redux-toolkit.js.org/tutorials/rtk-query/#advanced-example RTK Query | Redux Toolkit redux-toolkit.js.org 📍개요 RTK Query는 같은 쿼리를 subscribe하는 모든 컴포넌트가 항상 동일한(최신화된) 데이터를 가질 수 있도록 보장한다. 또한, HTTP 요청을 자동으로 중복 제거(de-dupes)하므로, 성능 최적화를 위해 진행중인 요청을 확인하거나 할 필요가 없다. 즉, 앱에서 다른 컴포넌트들이 동일한 쿼리로 컴포넌트의 state를 fetch해도, HTTP 요청은 1번만 발생한다.

1. mutation 이후 응답으로 받은 데이터를 전체 상태로 저장하기 장점 - HTTP 통신 1번만 필요 단점 - 코드가 복잡해질 수 있음 - 응답이 필요한 데이터를 포함하지 않을 수 있음 2. mutation 이후 새로 전체 상태를 받아오는 쿼리 실행 장점 - 구현 난이도 쉬움 - RTK 공식 문서에서 권장하는 방 단점 - HTTP 통신 2번 필

📍특정 유저의 앨범리스트를 query const { data, error, isLoading } = useFetchAlbumsQuery(user); - data : server에서 반환되는 데이터 - error : 에러 - isLoading (불린) : (최초에 1번만) 현재 로딩중이면 true, loading 완료되면 false - isFetching (불린) : 현재 로딩중이면 true, loading 완료되면 false - refetch : 쿼리 재실행 함수 📍특정 유저의 앨범리스트 추가 (mutation) - query가 컴포넌트가 렌더링되면 즉시 동작하는 것에 비해 mutation은 데이터를 바꿀 때 사용하는 함수를 제공 const [addAlbum, results] = useAddAlbumMu..

📍React-specific entry point import 방식의 장점 패키지 이름 뒤에 react를 뒤에 붙이면 endpoints에 해당하는 hooks를 자동 생성해줌 import { createApi } from '@reduxjs/toolkit/query' /* React-specific entry point that automatically generates hooks corresponding to the defined endpoints */ import { createApi } from '@reduxjs/toolkit/query/react' 📍reducerPath root state 객체에서 하나의 큰 프로퍼티 단위 - 예) albums, users 등 HTTP request를 다루는 많은 s..