일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | ||
6 | 7 | 8 | 9 | 10 | 11 | 12 |
13 | 14 | 15 | 16 | 17 | 18 | 19 |
20 | 21 | 22 | 23 | 24 | 25 | 26 |
27 | 28 | 29 | 30 |
- Cache
- 개발자
- front-end mocking
- 자바스크립트
- 아키텍처
- 기초
- react server component
- thread
- Babel
- 리액트네이티브
- amplify
- next.js
- 캐쉬
- 동기
- 비동기
- mockoon
- MSW
- vanilla-extract
- 기본
- styled-component
- react-native
- link
- sprinkles
- SWC
- CSS-in-JS
- Concurrent Mode
- 최적화
- mock service worker
- 리액트
- 컴포넌트
- async
- JavaScript
- 목킹
- React
- next hydration
- Critical Rendering Path
- 리액트쿼리
- 쓰레드
- Basic
- react-query
- Today
- Total
목록react-query (2)
Don’t worry about failures

react query를 간단하게 사용하면서 의문점이 생겼다. useQuery를 사용했을 때 reload을 했을 때 다시 api 요청을 했다. 이에 대해 궁금증이 생겨서 stackoverflow에 글을 남겼고, 이는 in-memory라는 것을 알게 되었다. 이를 기반으로 더 알아보고 좋은 글이 있어 번역을 기반으로 글을 작성해본다. 리액트 쿼리는 개발자 경험과 사용자 경험을 좋게 하기 위한 caching layer이다. 이는 in memory 캐쉬이며, 서버 없이, 브라우저 캐쉬와 관계 없이 처리되는 캐쉬이다. 나도 그러하고, 아마 많은 개발자들이 초기의 요청만하고, 그 이후에 캐쉬된 데이터를 제공 받기를 기대하며 이를 생각한다고 생각한다. 이 때문에 나 또한 의문을 가지고 찾아보기 시작한 것이다. Rea..

사이드 프로젝트를 하면서 react query를 적용해보기로 했다. 적용하게된 계기 1. 캐싱 작업 2. 서버 상태 관리 위와 같은 이유로 해당 라이브러리를 찾아보기 시작했다. 1. react query 2. swr 3. apollo 위와 같은 라이브러리가 존재했다. 모든 라이브러리를 비교 분석하기엔 어려움이 있었기 때문에. 간략하게 비교 분석이 된 것을 보고, react query를 선택했다. 그리고 이를 계속해서 파악해보았을 때 적용하는 데에 부족함이 없다라고 생각했기에 택하게 되었다. https://react-query.tanstack.com/comparison 훅과 같이 리액트 스럽게 사용할 수 있는 장점. 손쉽운 키로 캐쉬 관리 및 업데이트 등과 함께 서버 상태 관리를 직관적으로 표현. 이러한 ..