잠깐, SWR이 뭔데?

공식문서에도 나와있지만, 다들 눈에서 자동으로 필터링 했을 것이므로 한번 더 언급하자면, useSWR에서 SWR은 stale-while-revalidate의 약자이다.

<aside> 📌 stale-while-revalidate란?

RFC 5861에서 정의된 용어로, 캐시가 가지고 있는 stale response가 유효한 지 백그라운드에서 재검증하는 동안 해당 stale response를 즉시 리턴하여 네트워크 지연 시간을 숨기는 전략

stale response? 최신이 아닌 낡은 데이터 📖 stale(사전적 의미): 신선하지 않은, 낡은, 썩은

쉬운 예시) - 유통기한: max-age - 실제 음식이 상했는지? stale-while-revalidate ⇒ 유통기한 지났다고 음식을 못먹나? 그건 No No.

배민 예시) 나에게 보이는 화면은 “접수 전"인데 실제 사장님은 이미 접수를 했음 response가 전달되기 전에는 “접수 전"이라는 데이터는 stale한 상태

실제 response가 와서 상태를 업데이트 시켜주기 전까지는 client에서는 이러한 stale 데이터가 존재하기 마련.

캐시컨트롤 예시) Cache-Control: max-age=600, stale-while-revalidate=30 (캐시 유효기간은 5분, stale 기간은 30초로 설정한 상태)

- 600초 내에서는 이 데이터는 유효하다 → 계속 캐시에서 가져온다. (새로 요청 X)
- 600초가 지난 후 610초가 되었다면?
    → 이미 낡은 데이터. “stale”한 데이터로 취급. 일반적으로는 loader가 돌면서 API을 다시 호출해야함.
- 만약 stale-while-revalidate가 설정되어 있다면?
    → “캐시 유효기간이 지난 후에도 설정한 시간동안은 만료된(stale한 상태의) 캐시데이터를 받아오겠다”는 뜻
    → 610초에 조회 시 로더가 아닌 낡은 데이터를 일단 보여줌. 그동안 refetch가 진행되고 response가 오면 상태가 반영 됨.

그래서 stale-while-revalidate가 왜 좋은건데? - latency가 숨겨짐: refetching 동안 loader을 보여줘야 하는 불필요한 UI 변경을 막음 - 좀 더 유연하게 캐시데이터를 활용할 수 있음: 만료되었다고 무조건 끝이 아니다!! (유통기한 지났다고 못먹는 음식이냐!!)

</aside>

[LIVE] React Query와 상태관리 :: 2월 우아한테크세미나

위 컨셉을 적용한 것이 react-query, useSWR 등의 상태관리 라이브러리.

useSWR을 사용하는 가장 큰 이유

두 가지 이유가 있다.

하나는 “상태관리를 전역으로 하기 위해”,

두번째는 위에서 언급한 “**캐시를 효과적으로 사용하기 위해”**이다.

알고 보면 두 개가 연결된 것인데, 첫번째부터 설명하겠다.

상태관리를 전역으로 하는 것이 뭔가요?

리액트와 같은 프레임워크에서 변할 수 있는 값이라면 모두 “상태”라고 지칭한다.

이 상태는 기본적으로 컴포넌트 단위로 관리가 된다.

예를 들어 유저정보를 보여주는 <UserProfile/>이라는 컴포넌트가 있고 해당 컴포넌트가 userInfo의 상태를 갖는다고 하자.

<UserProfile/> 컴포넌트는 대략 이렇게 생겼을 것이다.