전에 완성했던 Travelog 프로젝트의 문제점을 찾아 공부하는 글
(제로초님의 로컬스토리지 세션스토리지 설명 참고)
LocalStorage와 SessionStorage의 차이점
이 둘의 차이점이 뭐냐면, 데이터의 영구성이라고 한다.
로컬스토리지와 세션스토리지 둘다 key value 형태인데, 정보를 로컬스토리지에 저장하면 브라우저나 탭을 닫았다가 다시 들어가도 로컬스토리지 내 정보가 저장이 되어있는 것이다(지우지 않는 이상 로컬스토리지에 정보 저장이 되어있음).
하지만, 세션스토리지는 다르다. 브라우저를 닫고 다시 들어가면 세션스토리지 속의 정보는 모두 없는 것이다.
이 차이점은 직접 경험할 수 있었는데, Travelog의 실시간 채팅 기능을 팀원이 구현하고 있는 중 나에게 로컬스토리지에 유저 정보를 저장할지, 세션스토리지에 할 지 물어본 적이 있다. 딱히 차이점을 알지 못해 전에 써본 로컬스토리지에다가 저장하라고 했었는데, 새로운 채팅을 구현하기 위해 새 탭을 띄웠을 때 그곳에서 유저 정보를 불러올 수 없던 것이다.
그래서 로컬스토리지에 유저를 저장하는 대신 다 세션스토리지로 바꿔서 저장을 했던 기억이 있다. 두 개 다 키 밸류 형태, setItem, getItem, removeItem, clear 모두 같기 때문에 이름만 바꿔줄 수가 있었다.
하지만, 이 두 군데에 절대 저장하면 안 되는 정보가 있는데 그건 비밀번호 같은 중요한 정보는 저장하면 안 되는 것이다! 정보 유출의 위험이 있기 때문에 이러한 정보를 클라이언트에 저장하면 안 된다.
또한, 이 글을 작성하기 위해 공부하며 새로 알게 된 점이 있는데 이 저장소들에 데이터를 저장할 때, 객체{} 형태가 그대로 저장이 되지 않는다는 사실을 알게 됐다. 객체 형식을 저장하고 싶을 땐, JSON.stringify()로 감싼 후 setItem을 해줘야 하고, getItem을 할 때는 전체를 JSON.parse를 감싸줘야 원하는 객체를 저장하고 가져올 수 있다.
데이터 패칭 라이브러리 React Query와 SWR(Stale While Revalidate)
React Query와 SWR은 데이터 패칭을 위한 라이브러리다. 프로젝트를 진행하면서 이미 같은 값에 대해 서버에다가 요청을 하는게 성능 최적화에는 그닥 좋은 방법이 아닌 것 같다는 생각이 들었었다. 그래서 찾아보며 알게 된 이 두 라이브러리.
이 둘은 데이터 캐싱하고, data, error, isLoading 등으로 상태 관리를 해서 더 나은 사용자 경험을 할 수 있게 해준다.
이들을 사용하는 방법이 둘다 굉장히 비슷한데, 리액트 쿼리는 useQuery를 이용해 사용할 수 있고, SWR는 useSWR를 이용하여 진행할 수 있다.
여기서 isPending과 isLoading의 차이점에 대해 의문이 들었다.
찾아보니, isPending은 데이터 패칭 status가 true일 때 데이터를 가져오는 중 상태인 것이고, isLoading은 데이터 패칭이 true나 false 상관없이 일단 요청을 하고 기다리는 중의 상태를 얘기하는 것이었다.
**(v5 이후부터 isLoading은 사라지고 isPending으로 대체한다고 한다)**
앞서 말했듯이 이 라이브러리들을 통해서 데이터를 캐싱할 수 있는데 여기서 나오는 cacheTime과 staleTime
cacheTime은 무엇이고 staleTime은 무엇일까?
**(v5 이후부터 cacheTime이 아니라 gcTime으로 쓰인다고 한다)**
cacheTime은 데이터를 캐싱하는 시간을 지정하는 것이나 밀리세컨 단위로 적어주며 적지 않으면 기본으로 5분이라고 한다. 캐시 타임을 정하면, 이 시간동안은 데이터가 캐시되어 있다고 한다. 하지만, 이 시간이 지나고 나서는 가비지 컬렉터로 이동된다고 한다.
staleTime은 캐싱 되어있던 데이터가 stale 되는 시간이라고 보면 된다고 한다(stale이 되면 서버에 데이터 요청을 한다). fresh한 상태의 캐시 데이터에서 stale 데이터가 되기까지의 남은 시간이라고 보면 되려나? 그래서 staleTime을 지정해주지 않으면, cached data는 계속 stale하다고 여겨지기에 계속 서버에 데이터 요청을 보내게 되는 것이다. 그럼 성능 최적화를 위해 이 라이브러리를 쓰는 이유가 사라지겠지?
결론!
이 cacheTime과 staleTime에 대해 조금 이해가 계속 가지 않았는데, 이제야 이해했다!
cacheTime은 한번 요청했던 데이터를 저장(캐시)해놓는 시간이고, staleTime은 저장된 데이터가 신선한 시간이다!
데이터 신선하지 않으면 api로 다시 요청을 해서 데이터를 업데이트하고, cachedTime은 지나지 않았지만 staleTime은 지났다면 전에 받았던 쿼리에 대한 cached data를 먼저 보여주고 그 사이에 api 요청을 새로 해서 다시 cached data를 업데이트 해주는 것이다 :)
현재 개발하는 프로젝트에서 React Query를 쓰고 있는데, 이 cacheTime과 staleTime에 대해 잘 알지 못해서 안 쓰고 있었다. 오늘 기회에 알게 됐으니 빨리 가서 코드에 적용 해봐야겠다~!~!
또, 여기서 staleTime은 cacheTime보다 짧아야 좋다라고 하는데 이에 대해서는 공부를 더 해봐야겠다. -> 신선한 시간이 데이터가 저장되어 있는 시간보다 길면 가비지 컬렉터로 이동이 됐을 때도 신선하다고 판단을 하게 되니 그런 건가 싶기도 하다
또 하나 알게 된 사실은, React Query는 Typescript와 React Native도 지원한다고 한다!(릴리굿)
