Conversation
- React page routing 구현
- tanstackquery 페이지 구현 및 axiosInstance 구현 예정, interceptor 제외
- 외부에서 QueryClientProvider 설정이 가능하게 creaateQueryClient 구현
- stale cache 문제 재현 및 확인 완료
|
|
||
| ## 결론 | ||
|
|
||
| 처음에는 InvalidateQueries가 좋지 않은 anti-pattern이거나 TQ에서 권장하지 않는 방식이라 생각했다. 개념을 다시 정리하고 살펴보면 단순히 cache의 신선도를 stale로 변경하고 해당 query가 호출, 구독된 컴포넌트(QueryObserver)를 마운트 언마운트에 따라 refetch가 결정되는 방식이란 것을 이해하고 다시 코드 useUsers.ts의 useUpdateUser함수를 보면 lists도 다음과 같이 invalidateQueries를 하면 되는 것 아닌가 싶었다. |
There was a problem hiding this comment.
query-key-facroty패턴을 통해 일괄적으로 invalidate시킬 수 있긴하지만, 이전 캐싱데이터의 참조에 의한 문제는 결국 optimistic update밖에 없을까 아쉬운 느낌이 드네요ㅠ
ex) 유저 A의 데이터를 업데이트 하고 onsuccess에 detail,list를 invalidate시킨 후 페이지를 이동해서 업데이트한 그 유저의 데이터를 useEffect를 통해 바로 사용하는 경우에는 이전 캐싱데이터를 참조해서 로직을 돌리기 때문에 문제가 발생하는 경우도 있을 것 같아요
There was a problem hiding this comment.
말씀하신 부분도 추가해서 다시 한번 재현을 해보겠습니다! 제가 이해한 이전 케시가 남아 있다는 부분을 stale의 비동기로 인해 발생한 문제로만 이해를 했는데요. 말씀하신 부분의 문제를 명료하게 한번 다시 보고 싶어서요! 감사합니다. 해당 PR에서 이어서 진행해보고 해결 방안을 한번 다시 한번 고려해보겠습니다.
더불어, invalidate를 query-key-factory를 일괄적으로 호출하면 api 호출이 2번 발생할 수 있는 점이 마음에 걸리긴하네요.. 물론 cache를 디테일하게 관리하고 검증한다면 호출 빈도를 안정적으로 맞출수는 있지만, 좀더 네트워크 측면으로 생각해보겠습니다.
잘못된 이해를 바탕으로 답변이 되었다면 피드백 감사하겠습니다.
There was a problem hiding this comment.
문득 들은 생각인데, onSuccess일 경우에 굳이 invalidate시키지말고 queryClient.fetchQuery로 재호출해줘도 괜찮을 것 같다고 생각이 드네요! 이런식으로도 update가 잘 반영되는지도 체크해보면 좋을 것 같아요
There was a problem hiding this comment.
넵, 해당 부분도 탐구하고 추가해서 작성해 놓겠습니다. 감사합니다.!!
cc. @KimKyungYun @za0012
| import axios from "axios"; | ||
|
|
||
| // TODO: AB테스트가 용이하게 함수로 수정 필요 | ||
| const API = 'https://698b4bb16c6f9ebe57bc3edb.mockapi.io/api/v1' |
There was a problem hiding this comment.
간단한 DB까지 제공해주는 mock API 사이트인가보네요 좋네요!
There was a problem hiding this comment.
맞습니다. @KimKyungYun @za0012 해당 mock API는 공통 google 계정을 만들어서 공유하고 함께 사용하기 좋을거 같다 생각합니다. 주말에 설정할 수 있도록 하겠습니다.
| /** | ||
| * @description 대규모 도메인 관리라 가정하고 생성한 함수이다. 따라서, createQueryClient는 micro frontend와 같은 개념으로 접목해서 사용하면 좋겠단 생각을 했다. | ||
| * @deprecated 해당 함수를 각 페이지별로 override해서 관리해보려 했으나. 이는 캐시 분리, 데이터 공유 불가, 메모리 낭비와 같은 안티 패턴이다. | ||
| * @remark 추후 전역 관리로 이관 예정, 외부에서 주입을 할 떄 보다 좋은 방법이 있으면 좋겠다. 더불어 페이지가 아닌 성격이 다른 도메인과 같은 곳에서 사용하면 효과적이다. |
There was a problem hiding this comment.
캐싱데이터를 공유하면서 옵션만 따로 제공하려면, 하나의 QueryClient를 최상단에서 제공하고, 하위에서 옵션만 분리적으로 주입할 수 있는 방법을 찾아보는것도 좋을 것 같네요 👍
2 participants
Summary
TQ의 InvalidateQueries의 동작 방식과 InvalidateQueries의 문제점을 문서화 했습니다. InvalidateQueries가 단순히 문제가 많다는 입장이였으나, 다른 환경, 상태에 따라 InvalidateQueries를 사용하는 것이 크게 문제가 되지 않을 수 있겠다는 생각을 했습니다. 이에 따른 반문과 비평과 여러분의 생각이 필요합니다. 코멘트 부탁 드립니다.
Changes
주의 깊게 봐주실 부부은 다음과 같습니다.
useUsers.ts의useUpdateUser함수 부분입니다.