react-query는 요청을 전송하는 로직이 내장되어 있지 않고, 단순히 요청을 관리하는 로직을 제공하기에, 내가 요청 전송 로직을 따로 생성해줘야 한다.
궁금해!
궁금한 점이 생겼다. 보통의 http 요청 로직에서는 try-catch문을 통해 에러 핸들링을 했었다. 근데 리액트 쿼리는 isError와 error라는 메서드를 통해 에러 정보를 제공해 준다.
그러면 try-catch문을 따로 사용하지 않아도 되는 것.. 인가?? 아니 당연한 거 같기도 한데.. 맞나?!
실험
jsonplaceholder의 잘못된 경로로 요청을 보내봤다.

try-catch문을 통해 error가 출력되게 했다.

늘 먹던 대로 하던 대로 에러가 출력되는 것을 확인할 수 있다. 이제 진짜 궁금한 것을 확인해 봤다.

try-catch문을 제거하고 react-query의 error 메서드를 통해 error를 console.log로 출력해 봤다.

똑같이 에러가 잘 출력되는 것을 알 수 있다.
차이점을 찾아보자면 try-catch문에서의 에러 핸들링은 useQuery의 queryFn에서 실행되기에 선행(?)적으로 실행된다는 것이고, useQuery의 error 메서드는 3번의 재요청 시도가 끝난 뒤에 최종적으로 실행된다는 것이다.
결론
react-query를 사용할 때는 굳이 try-catch로 에러 핸들링을 할 필요가 없다.
더 찾아본 결과
queryFn으로 http 요청 메서드를 실행시키면 그 결과 값은 react-query의 시스템이 관리하게 된다. 즉 queryFn에서 에러가 발생하면 해당 에러는 useQuery 훅이 자동으로 캐치하고 에러 상태를 처리하게 됨!
코드가 훨씬 간결해지고, 에러 처리도 알아서 해주는 것이다.. 갓스택 쿼리.. 킹스택 쿼리.. 짱스택 쿼리..
항상 최소한으로 얕게 배운 뒤 바로 쓰려고 하니, 이런 개념의 구멍들이 생기는 듯하다. 그래도 나름 이런 걸 찾아가는 재미도 있다! 내가 모르는 또 어떤 엄청난 기능들이 있을지 궁금하다. 계속 써보면서 알아가는 걸로 ~,~
'프로젝트 > 학수고대 프로젝트' 카테고리의 다른 글
눈물겨운 사용자 경험 개선하기 (0) | 2024.04.04 |
---|---|
position을 지양하..지는 말고 생각 좀 하고 쓰자 (0) | 2024.04.03 |
Zustand 사용기 (2) | 2024.03.17 |
함수형 컴포넌트 onClick 실행안되는 원인 (0) | 2024.03.11 |
아니 땐 굴뚝에 hover 날까 (0) | 2024.03.11 |