useMutation?
useMutation은 그 이름대로 mutation을 위한 패칭 메서드로, react-query에서는 일반적인 get요청에 대해서는 useQuery를 사용하라고 권하지만 CUD(create, update, delete) 와 같이 서버의 데이터값을 변경시킬 수 있는 사이드이펙트 요청에 대해서는 useMutation을 사용하길 권하고 있다.
그래서 나는 당연히 구글링을 통해 사용 용례를 "쉽게" 찾아보려고 했고, 그게 화근이 될 줄 몰랐다.
구글링을 통해 방법을 찾아보면, 정말 수도없이 많은 방식으로 정의한 자신만의 방법들을 볼 수 있다. 혼돈의 도가니
그래서, 그냥 공식문서를 보기로 했고 공식문서대로 만들면서 겨우 이해가 되었다 이게 무슨의미인지
용례
위는 현재 코드에 설정해둔 mutation 코드이다.
참고로
초기 컨텍스트로 설정한 해당 QueryClient( 쿼리들의 값들이 저장된 캐시 저장소 ) 에 대해서 불필요한 옵션은 꺼둔 상태이다.
저게 켜져있으면, 굳이 리패칭이 필요하지 않은 페이지에서도 윈도우가 포커싱이 되거나 네트워크가 바뀔 때에 멋대로 요청이 또날아가서 꺼뒀고 필요할 때마다 옵션으로 주는게 좋을 것이다.
중요점
useMutation이 호출이 되면 나오게 되는것은 리턴되는 객체의 기본 형태에는 상당히 비슷한 부분이 많다.
그런데 중요한 부분은 이 자체만으로 서버에 요청이 날아가는 것이 아니라(useQuery때처럼)
내부의 "mutate" 함수를 호출해야만 요청이 간다는 점이었다( 즉, onSubmit과 같은 이벤트에서 mutate 함수가 호출될 때 비로소 요청이 날아간다 )
그리고 나면 내부에 주어지는 객체의 프로퍼티들이 응답에 따라서 자동으로 업데이트가 되는데(이건 next.js 팀에서 만든 swr와 하는 행동이 비슷하다)
문제는 이 값들을 굳이? 이용할 필요가 없다는점이다.
저 값들이 필요한 상황이라는 뜻은 조건부로 무언가를 처리할 상황이라는 의미인데 그래서 저 값들을 가지고 요청을 처리하려면 이처럼
불필요한 useEffect가 들어가는 골치아픈 로직이 짜질 수 있다.
그러나, 굳이 그럴 필요가 없었던 것이 위에 프로퍼티 내용에서 보이는 "isSuccess, isLoding, isError" 와 같은 것들이다.
저 내용에 함수를 담으면, 콜백형태로 처리가 되는 구조로 되어있다. 그래서 위의 useEffect를 걷어내고 이처럼
useMutation의 두번째 인자로 콜백을 담당할 함수들을 전달하면 되는 일이었다...
이 외에도 캐싱과 관련한 행위 처리를 위해 고민을 해봐야겠지만, 확실히 react-query의 장점이 분명하게 존재한다
- 불필요하게 loading, error, success 상태를 분류해서 만들 필요가 없다. 알아서 비동기적으로 다 처리해준다
- 캐싱과 관련한 내부로직덕택에 항상 신선한 데이터를 보여줄 수 있다
Next.js와 연동을 생각한다면, next.js는 항상 미리 랜더링해둔 최신 정적 페이지를 준비해서 제공하고, 클라이언트측에선 이 정적인 페이지의 내용을 지속적으로 react-query를 이용한 조건부 캐싱, 그리고 리패칭 기능을 통해서 항상 가장 최근의 데이터를 보여줄 수 있게 한다.
왜나하면 Next.js는 초기 전달 이후로는 특정 요청이 있지 않은 한 내부적으로 CSR을 따르기 때문에 그렇다. 즉, SEO와 빠른 초기 랜더링의 장점, 그리고 지속적인 데이터 피드백을 통한 최신 업데이트 두마리의 토끼를 다 잡을 수 있는 좋은 기술이라고 생각한다.
