왜 TanStack Query에서 onSucces 를 제거했을까 ? #16
Unanswered
yunseorim1116
asked this question in
Q&A
Replies: 1 comment 2 replies
-
우와 신기하네여 :) |
Beta Was this translation helpful? Give feedback.
2 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
So, why would we remove an existing API, seemingly without alternatives?
Simply put: Because it's a bad API that likely doesn't do what you'd expect. The most important thing about APIs is that they are consistent, and the callbacks are not.
| 기대한 대로 작동하지 않을 가능성이 높은 나쁜 API이기 때문입니다.
A bad API
useQuery에는 세 가지 콜백 함수인 onSuccess, onError, onSettled가 있으며, 쿼리가 성공적으로 실행되었거나 오류가 발생했을 때(또는 두 가지 경우 모두) 호출됩니다. 이 함수를 사용하여 오류 알림 표시와 같은 부수적인 효과를 실행할 수 있습니다.
콜백은 직관적이지만...
여러 컴포넌트에서 동일한 useQuery를 호출할 때 일관성 문제를 일으킬 수 있습니다. 두 컴포넌트가 각각 콜백을 실행할 경우, 오류 알림 등이 중복되어 실행되거나 비일관적인 동작이 발생할 수 있습니다.
대안으로
React Query에서는 전역 캐시 수준에서 콜백을 사용하는 방식을 제안했습니다. 이를 통해 컴포넌트 간 일관성을 유지하면서 부작용을 관리할 수 있으며, meta 필드를 활용하여 각 Query마다 다른 오류 메시지를 보여줄 수도 있습니다.
또한
콜백을 통해 상태를 동기화하는 패턴은 추가 렌더링 사이클을 유발하여 잘못된 상태를 렌더링할 가능성이 있습니다. 이를 해결하기 위해 상태를 파생시켜 사용하는 방법을 제안하며, 추가 렌더링 사이클을 방지하고 데이터가 일관되게 유지되도록 해야 합니다.
결론적으로
React Query는 비일관적인 API 패턴을 제거하고 보다 일관된 방식으로 상태와 부작용을 관리하기 위해 API를 변경하고 있으며 이 과정에서 사용자 경험을 개선하려는 노력이 반영되었습니다.
마지막
처음 구현할 때는 원하는 대로 동작할 가능성이 높지만, 앱의 성장에 맞춰 리팩터링이나 확장을 할 때 대가가 따르기 때문에 아주 좋지 않습니다. 또한 우리가 에러 발생에 취약한 상태 동기화를 도입할 때 이게 나쁘다는 걸 느낄 수 없게 하므로 안티 패턴을 초래합니다.
출처
https://tanstack.com/query/v5/docs/framework/react/guides/migrating-to-v5
https://tkdodo.eu/blog/breaking-react-querys-api-on-purpose#major-changes
https://velog.io/@cnsrn1874/breaking-react-querys-api-on-purpose
Beta Was this translation helpful? Give feedback.
All reactions