react-query를 짧게 사용해본 회고..랄까...?

지금 진행하고 있는 프로젝트에서 react-query와 recoil을 사용해서 상태관리를 해주고있다.

물론 프로젝트가 아직 끝나지 않았다ㅎㅎ..

사실 작년까지만 해도 채용공고나 그런 곳들에 Redux가 가득찼었는데 어느 순간부턴가 React-Query의 점유율이 높아지기 시작했다.

공부해야지..해야지..생각하다가 사용하고있는 프로젝트에 우연히 들어가게 되면서 해야만하게 됐다..

리코일은 이전에 학습해봤는데 리액트 쿼리는 안해봐서 살짝 겁이 났었다

근데 지금 해보니 적용하고 사용하는 데에 있어서는 크게 어렵지 않으니 나처럼 겁먹은 사람이 있다면 일단 해보라고 말하고 싶다.

 

일단 도대체 요즘 왜 다 리액트 쿼리를 사용하는 건지에 대한 의문이 들었었다.

이해해보려고 자료를 많이 찾아봤는데 자료도 자료지만 직접해보고 깨닫는게 제일 이해가 잘 됐었다.

그래서 자료는 도입을 해서 기존의 상태관리를 리액트 쿼리로 바꿔본 그런 글들을 많이 봤다.

그래서 짧지만 두 달가량 사용해본 찌랭이인 내가 어떤 점을 느낄 수 있었는지에 대해 적어보려고한다.

진지한 글은 아니다...그냥 내가 해본 얕은 깊이에서 느낀 글일뿐..

 

적용한 이유

위 사진은 공식문서로 가면 이런 화면을 볼 수 있을것이다.

내 눈에 제일 보인 것은 ASYNCHRONOUS STATE MANAGEMENT였다. 바로 '비동기 상태관리'라는 거다.

wow 오늘도 나오는 비동기

공식문서에 따르면 리액트 쿼리는 React에서 서버상태를 가져오고, 캐싱, 동기화, 업데이트하는 작업을 쉽게 수행할 수 있도록 도와주는 모듈이다라고 말한다.

사실 그렇게 규모있는 프로젝트를 해보거나 사용자가 엄청나게 많은 서비스를 관리해본 경험이 없어서 그런지 기존의 위의 부분에 크게 불편함을 느끼지 못했었다.

근데 참 신기한게 이번 프로젝트를 하면서는 불편한 점을 느꼈었다.

사실 이번 프로젝트에 리액트 쿼리를 사용했어야했는데 익숙치않아서 처음에 내가 하던 방식대로 api 호출을 했었다.

그러다보니 의도치않게 불편한 점을 느끼고 해결한 셈이 됐다,,,호호,,

 

내가 느낀 불편함은 화면을 초기 구동할때 api호출을 하면 로딩이 오래걸린다는 것이었다

이번 프로젝트가 React Native로 이루어진 어플을 만드는 것이다보니까 로딩화면 하나하나에 굉장한 불편함이 크게 느껴졌었다.

나는 sns서비스의 프로필 부분을 담당했었는데 프로필페이지는 생각해봤을 때 프로필사진, 닉네임, 계정이름, 팔로워, 팔로잉, 포스트 등 불러올 정보들이 많다.

이게 한 api로 온다면 좋겠지만, 또 분리가 되어서 오는 경우도 많다. 

그러면 하나의 api를 호출하는데도 시간이 걸린다!? 그렇다면 여러 api를 부른다면??
그렇다면 더 오래걸리는거다,,

왜인지 모르게 앱에서의 로딩이 웹에서의 로딩보다 체감적으로 길게 느껴지는 것 같았다. 화면이 작아서 그런가..?

뭔가 앱은 웹보다 더 작은 화면에서 페이지간 이동이 빠르게 나타나기때문에 그렇게 느낀다고 혼자 생각했다.

하여간 이 api를 호출하느라 빈화면이 나오는 시간이 길다고 느껴지는 건 나뿐만 아니라 팀원들도 그렇게 느꼈기 때문에 이를 개선할 때 다른 추가적인 개선방법도 있었지만 React-query도 한 몫했다.

 

일단 내가 느낀 제일 좋았던 기능 중에 하나는 뭐니뭐니해도 '캐싱', '에러핸들링'이었다.

그리고 빼놓을 수 없는 '코드가 단순해짐'이 굉장한 장점이다.

 

코드의 단순화

내가 참고했던 아티클중에 리액트 쿼리를 통해 BoilerPlate의 감소를 손에 꼽았다.

사실 리덕스를 사용하면 제일 먼저 겪는 문제 중에 하나가 러닝커브이다.

물론 학습할 때에도 굉장한 러닝커브가 있지만, 도입에 있어서도 굉장히 많은 코드의 양이 적혀지고, 로직적으로 이루어졌다고 할 수 있다.

리듀서, 액션, 상태 등등 분리가 되어있어 굉장히 분기성이 좋지만, 그만큼 적어야하는 코드의 양이 많았다.

 

리액트 쿼리에서는 코드가 눈으로 봐도 확줄었다.

const userInfo = useQuery<UserProfile>(['userProfile', userId], () =>
    getUserProfile(userId),
  );

이 행위 하나로 api 호출 핸들링이 가능해진다.

코드의 단순화라고 하면 따라붙는 것들 가독성,,유지보수에 이점,,이다.

가독성은 내가 중간 투입돼서 코드를 봤던 프로젝트라 react query를 적용하는데 큰 어려움이 없었다는 걸 통해 알 수 있었고, 유지보수는.. 일단 크게 느낀 부분은 없지만, 연쇄적으로 내가 이해하기 쉬우면 수정하거나 적용하는데도 용이할테니까 유지보수에 있어 용이할 것이라는 것은 어림짐작할 수 있다.

 

API 호출 핸들링

리덕스로 비동기처리를 해주기 위해서는 미들웨어부터 state 구조까지 굉장히 복잡하게 생각하고 설계해야했다.

위에서 리액트 쿼리는 자신있게 비동기 상태관리를 위해 만들어졌다고 공식문서에 작성되어있는만큼 다방면에서 도와줬다.



리액트 쿼리에서는 단순한 옵션 (내가 사용했던건 isLoading,,)들을 사용해서 쉽게 핸들링할 수 있고, 사용자경험까지 쉽게 높일 수 있다.

이런 에러핸들링을 통해 에러메시지를 띄운다던지와 같은 UX를 고려한 기능들을 생각해볼 수 있다.

const postIdList = useInfiniteQuery(
    ['FeedPostList', userId],
    ({pageParam}) => getPostIds(userId, {pageParam}),
    {
      getNextPageParam: (lastPage, pages) => {
        if (lastPage.data.last === false) {
          return pages.length;
        } else {
          return undefined;
        }
      },
    },
  );

위를 보면 useInfiniteQuery를 통해 무한슬라이드?와 같은 기능을 구현한 코드이다.

이런 것처럼 리액트 쿼리에서의 용이한 기능들을 가지고 쉽게 구현할 수 있는 방법들이 많다.

 

캐싱

뭐니뭐니해도 캐싱

내가 리액트 쿼리의 캐싱을 간편하다라고 느낀 것은 바로 key때문인것같다.

const likeMutation = useMutation({
    mutationFn: () => putPostLike(postId),
    // When mutate is called:
    onMutate: async () => {
      // Cancel any outgoing refetches
      // (so they don't overwrite our optimistic update)
      await queryClient.cancelQueries({queryKey: ['post', postId]});

      // Snapshot the previous value
      const previousPost = queryClient.getQueryData<FeedPost>(['post', postId]);
      if (!previousPost) {
        return null;
      }
      // Optimistically update to the new value
      if (previousPost?.isLike) {
        queryClient.setQueryData(['post', postId], {
          ...previousPost,
          isLike: false,
          likeCount: previousPost.likeCount - 1,
        });
      } else {
        queryClient.setQueryData(['post', postId], {
          ...previousPost,
          isLike: true,
          likeCount: previousPost.likeCount + 1,
        });
      }

      return {previousPost};
    },
    onError: (_err, _newTodo, context) => {
      queryClient.setQueryData(['post', postId], context?.previousPost);
    },
    onSettled: () => {
      queryClient.invalidateQueries({queryKey: ['post', postId]});
    },
  });

useMutate를 통해서 서버의 상태를 변경시킬 수 있다.

이 안에서 key와 setQueryData, invalidateQueries 등을 통해 분리해서 해당 key에 해당되는 데이터를 기록하고, 삭제하고, 갱신하는 이런 동작들을 구현할 수 있다.

 

이런 캐싱이 나한테는 뭔가 혁명적으로 다가왔다. 비슷한 정보를 아이디값에 따라 다른 데이터를 저장하는 것처럼 작용하면서 뭔가 말할 수 없는 편리함?을 느꼈다..

 

 

 

이런 편리함 하나하나가 쌓여 개인적으로 개발함에 있어서 내가 쓴 코드에 헷갈리게 반응하는 것 없이 로직을 구현할 수 있었다.

정말 개인적으로 러프하게 느낀 점들이라서 맞지 않는 정보가 있을 수도 있는데 그런것들은 알려주시면 좋을것같다.

아직 프로젝트가 끝나지 않았으니 계속 사용해보고 다시 또 다른 느낌으로 회고?글을 작성해볼 수 있는 경험이 또 발생했으면 좋겠다🙄

---

참고

https://tanstack.com/query/v3/

https://tech.kakao.com/2022/06/13/react-query/

https://www.youtube.com/watch?v=41tFNtwWE3o 

https://tech.kakaopay.com/post/react-query-1/#redux-%EC%9D%B4%EA%B1%B4-%EB%B6%88%ED%8E%B8%ED%96%88%EB%8B%A4