swr (stale-while-revalidate)
<SWRConfig>
를 사용해서 global configuration을 할 수 있다. graphql을 사용할 경우 endpoint가 하나이기 때문에 fetcher를 global로 미리 등록을 해주어도 좋을 것 같다.
fetcher
안에서 에러가 발생되면 hook에 의해서 error
가 return 된다.
fetcher
안에서 status code에 따라서 에러를 custom 해서 throw 할 수도 있다.참고
onErrorRetry
옵션을 통해서 에러가 발생했을 때 retry를 조절할 수 있다.참고
useSWR
의 첫번째 인자인 key
에 falsy한 value가 주어지면 SWR이 request를 보내지 않는다. 함수나 조건부 삼항 연산자를 이용해서 fetching을 할 지 말지 결정할 수 있다.
또한 한 요청의 결과를 이용해 다음 요청을 보낸다면 serial fetching이 된다.
부모 컴포넌트에서 자식 컴포넌트로 어떤 데이터를 전달해야하는지 알 필요가 없다. 또한 자동으로 캐시를 하고 공유하기 때문에 request를 한 번만 보낸다.
만약 user 정보를 가지고 데이터를 fetching 해야하는 경우가 있다고 하면,
위와 같이 코드가 작성되는데, request의 key가 두 값의 combination이 된다. SWR은 render할 때마다 arguments를 얕은 비교를 하고 바뀌었으면 revalidation을 한다. 따라서 redering을 할 때마다 object를 다시 만드는 것은 좋지 않다.
같은 key를 가진 SWR들에게 revalidation message를 mutate(key)
를 통해서 revalidation 할 수 있다.
대부분의 경우에 mutate
를 사용해 local data를 업데이트 한 다음에 revalidation을 하는 것이 더 속도가 빠르다.
만약 api가 업데이트 된 결과를 반환하면 다음과 같이 코드를 줄일 수 있다.
mutate의 두 번째 인자로 async 함수를 넣으면 매개변수로 현재 캐시된 값을 받는다.참고
refreshInterval
옵션을 사용해서 interval을 지정할 수 있다.mutate를 사용하여 로컬 데이터를 최신으로 업데이트 하는 동시에 유효성을 검사하고, 마지막으로 최신 데이터로 바꿀 수 있다.
mutate를 swr로 불러서 사용했을 경우, key 값을 넣어줘야한다
두번째 인자로 true 값을 주었을 때 먼저 newName를 캐시에 추가하고, DB와 비교해서 최신 값을 보여준다. false 로 주었을 때, revalidation을 하지 않는다.
SWR은 캐싱과 deduplication을 통해서 불필요한 네트워크 비용을 줄인다.
같은 키를 가진 useSWR
hook을 여러 곳에서 쓰는 경우가 많다. 그런 경우 하나의 네트워크 요청만 가도록 한다.
SWR은 data 변화를 깊은 비교를 한다. data가 변하지 않으면 리렌더링이 되지 않는다. 만약 비교 함수를 customize 하고 싶으면 compare
옵션을 사용할 수 있다.
useSWR
은 3개의 state를 나타내는 값을 가진다. 그리고 이 세가지는 독립적으로 업데이트가 된다. 따라서 다음과 같은 코드가 있을 때 data
, error
, isValidating
의 변화는 5단계가 될 수 있다.
코드
결과
그러면 component는 5번 리렌더링이 된다. 이 문제를 고치기 위해서 data
만을 컴포넌트가 사용하도록 할 수 있다.
코드
결과
재남님 useSWR 무한스크롤 blog
SWR 공식 문서
SWR use Hook
tech sharing