(가짜아님)
이제는 프론트엔드에서 redux
로 서버 상태를 관리하는 것이 아닌 react-query
로 관리하는 프로젝트가 점점 많아지는 추세이다.
그에 따라 "이참에 나도 한번~??" 하며 입문하는 사람도 많아지고 있다.
react-query
의 장점은 서버 상태의 분리로써 얻는 장점 이외로도, 간단한 에러 또는 로딩 처리가 있다.
그런데 아마 이 부분을 하며 react-query
가 제공하는 값들을 보다 보면 궁금한 점이 생겼을 것이다.
isLoading
이랑isFetching
은 뭐가 다른거지...?
이번에는 이러한 고민을 했던 사람들을 위해 간단하게 정리해보고자 한다.
react-query
의 장점에는 데이터를 캐시해서 전달하는 것이 있다.
쉽게 말해서 react-query
가 자체적으로 서버 데이터를 저장하고 있다가 api 요청 없이 해당 데이터를 보여준다는 것이다.
이 기능을 통해 불필요한 api
호출을 줄일 수 있다.
엥? 그럼 안되는거 아님? 서버 데이터 바꿔졌으면 어떡하려고 🤨
똑똑한 react-query
개발자들은 당연히 방법을 다 생각해 두었다.
이 부분에서 react-query
는 stale
과 fresh
라는 개념을 사용하는데, 간단하게 음식을 생각하면 좋다.
1.유저
가 react-query
한테 국밥(data
)를 요청
2-1. react-query
는 캐시에 신선한(fresh
)국밥이 있으면 그대로 줌
2-2. 캐시에 상한(stale
)국밥이나, 국밥 자체가 없으면 서버
에 국밥(data
) 받아와서 줌
(해당 글은 react-query
에 대해 설명하는 글이 아니기 때문에 그냥 그런 개념이 있다는 것만 전달한다.)
(stale
에 대한 자세한 내용은 구글에서 검색해보자)
국밥이 상하고 어쩌고.... 그게
isLoading
과isFetching
이랑은 무슨 상관이죠? 😶
사실 stale
이 중요한게 아니고, react-query
가 데이터를 캐싱
한다는 점이 중요하다.
isFetching
은 어떠한 react-query
요청 내부의 비동기 함수가 처리되었는지 여부 에 따라 true/false
로 나누어 진다.
isLoading
은 캐시된 데이터조차 없이, 처음 실행된 쿼리 일 때 로딩 여부에 따라 true/false
로 나누어 진다.
즉, 결론적으로 isLoading
과 isFetching
은 비슷하게 '로딩' 이라는 개념을 사용하지만 기존에 캐시된 데이터가 있느냐 에 따라 다르다.
아.... 근데 그건 언제 쓰죠? 굳이 나눌 필요가 있나요? 🤔
간단하게 생각하자면 isLoading
은 어떤 데이터를 처음 가져올 때 사용하면 되고,
isFetching
은 데이터를 다시 가져와야 할 때 사용하면 된다.
그 두개가 달라야 하나? 싶을텐데, 다시 한번 국밥을 생각해보자.
국밥을 처음 가져올때는 숟가락, 젓가락, 물도 가져다줘야 하지만, (isLoading
)
다시 한번 주문하면 국밥만 가져다 준다. (isFetching
)
이처럼 두 경우에 있어서 작업의 차이가 필요할 때 사용 한다고 보면 되겠다.
이쯤되니 이게 react-query
얘긴지 국밥집 창업 얘기인지 모르겠지만, 아무튼 모르고 넘어가기엔 은근 영향이 있는 부분이다.
isLoading
과 isFetching
을 적절한 곳에 적절히 사용해서 사용자들에게 더 좋은 UI/UX
를 제공해보자.
isLoading
은 서버에 데이터 요청을 처음 할 때isFetching
은 서버에 데이터 요청을 다시 할 때 (캐시된 데이터가 있을 때)+ 읽어주셔서 감사합니다.
+ 오타, 내용 지적, 피드백을 환영합니다. 많이 해주실 수록 제 성장의 밑거름이 됩니다.
비유가 재밌어요! 이해가 잘되네요