이번 회사 프로젝트를 하면서 굉장히 진귀한 경험을 했다...

사실 별 것 아닐 수도 있지만
실제로 경험해보지 못한 사람들은 절대 와닿을 수 없을 것이다!

그 주인공은 바로

cacheTime

그렇다. 오늘은 cacheTime이라는 것에 대해 알아보도록 하자

cacheTime 정의

cacheTime을 간단히 정의해 보면 이렇다.

• 데이터가 활성화 되어 있지 않을 때 캐싱되어있는 시간
• cacheTime이 지나기 전에 refetch를 했을 경우, 데이터를 fetch하는 동안 캐싱된 데이터를 보여줌

쉽게 말해서..? 캐싱된 데이터를 유지할 시간을 말한다.

그리고 useQuery에서 default cacheTime은 5분이라고 공식문서에 나와 있다.

잠자는 cacheTime을 건드리다

useQuery를 쓰면서도 아마 cacheTime는 거의 볼 일이 없다고 생각한다. 그 이유는 굳이 cacheTime를 건드릴 필요가 없다는 것? 때문이다

하지만 이번에 정말 우연치 않게 cacheTime를 건드려 보았는데...

건드린 이유는 바로 loading 때문이다

const {data, isLoading} = useQuery...

데이터가 로딩되기 전까지 위의 isLoading을 사용하여 loading 로티를 보여주고, 데이터가 비로소 fetch되었을 때 화면에 데이터가 나오도록 하고 싶었다.

그런데 저 isLoading을 사용할 경우, 로딩 로티가 돌지 않고, 이전 데이터가 남아 있다가 바로 다음 데이터로 넘어가는 굉장히 부드럽지 않은 화면 전환이 일어났다.

'이는 분명 cacheTime 때문이다'

라는 결론을 빠르게 내린 나는 로딩이 필요한 곳에서 자신있게

cacheTime: 0

캐시 타임을 초기화해버렸고,

cacheTime이란 것을 잊고 코딩한지 어언 3개월이 지나고,
실제 출시를 앞둔 React Native 앱에서는

발열 / 배터리 소모량 대폭 증가 / 앱 크래시

라는 3단 시련이 찾아와버렸다.

최적화 문제인가,
데이터가 너무 커서 그런가,
다른 사람들은 안그러던데,
왜 내가 만든 어플에만 그럴까,
(그렇게 나의 이전 글이 탄생해버리고 말았다)

참회의 시간

그렇게 끝도 없는 최적화를 거치며 최적화 마스터가 되어버렸지만 그럼에도 위 현상은 변하지 않았다.

그러다 문득 든 생각

다른 사람들의 레포와 내 레포가 다른 점은 무엇일까?
cacheTime

이 뇌리를 스쳐갔다.
(이땐 정말 마지막 밧줄을 잡는 느낌이었다...)

그렇게 모든 cacheTime 초기화 코드를 삭제하고
다시 testFilght를 통해 앱을 테스트 해 본 결과

...

...

...

발열이 없어졌다!
...
..
.

동작도 훨신 더 자연스러워졌고 비로소 앱다운 앱이 탄생해버렸다

끝

(은 아니고)

평소라면 정말 신경쓰지도 않았을 cacheTime의 역할 대해 몸소 느끼게 되었고 캐싱이란 것은 나중에 캐시가 쌓여서 우릴 귀찮게 하더라도, 빠른 속도와 성능에는

반.드.시

필요한 동작이라는 것을 알게 되었다.

앞으로는 캐싱이라는 것에 대해 감사함을 느끼며 코딩을 할 지도..?

헤헤

진짜 끝