SEE-NEAR 리액트 쿼리 적용

들어가며

우리팀은 서버를 Django의 runserver를 통해 배포해서 사용중이었다. 찾아보니 보안적, Django의 runserver는 성능적으로 효율적이지 못하므로 배포 시에는 별도의 웹 서버가 필요했었다.

때문인지 간단한 이벤트를 get하는 api를 호출하는데에도 굉장히 많은 시간이 걸렸다.

하지만 서버쪽에서도 쉽지 않게 배포를 마친 점을 알고 있었기에 최대한 클라이언트 쪽에서 서버의 느린 속도를 보완할 점을 찾아야 했다.

기존의 상황

캘린더의 각 날짜를 누를 때 날짜는 빠르게 변경되지만 오늘의 일정은 날짜 변경에 비해 느리게 불러와지고 있었다. 이는 사용자가 충분히 불편을 느낄만한 속도 차이였다.

  // 기존의 코드
  
  const [todos, setTodos] = useState<EventDto[]>([]);
   
  useEffect(() => {
    const fetchEvents = async () => {
      try {
        const response = await axiosEventsCheck(selectedDate);
        setTodos(response);
      } catch (error) {
        console.error(error);
      }
    };
    fetchEvents();
  }, [selectedDate]);

기존에는 useEffect를 이용해서 선택한 날짜가 변경될 때마 axios를 호출하는 방식으로 구현했었다. 그러다보니 이전에 선택한 날짜를 다시 누르게 되어도 api 호출이 일어났고 여전히 느린 속도로 데이터가 불러와졌다.

따라서 조금이라도 데이터 패칭 속도를 보완하기 위해 서버 상태를 캐싱할 수 있는 react-query를 적용해보기로 했다.

또한 이전에 useEffect를 지양해야하는 이유에 대해 알았기에 더욱 useEffect를 통한 데이터 패칭이 아닌 react-query를 통한 데이터 패칭을 도입하고 싶었다.

react-query 도입

변경된 코드는 다음과 같다.

export const useGetEvents = (date: string) => {
  const { data, error, isError } = useQuery<EventDto[], Error>({
    queryKey: ["events", date],
    queryFn: () => axiosEventsCheck(date),
  });

  return { data, error, isError };
};

const { data: todos = [], error, isError } = useGetEvents(selectedDate);

확실히 react-query는 코드가 간결하고, 제공하는 파라미터를 통해서 쉽게 서버의 로딩 및 오류 상태를 관리할 수 있었다. 무엇보다 캐싱을 통해 빠르게 서버 상태(데이터)를 가져올 수 있었다.

리액트 쿼리 적용 후 캐싱한 날짜에 한해서는 위의 동작처럼 즉시 사용자에게 데이터를 제공할 수 있었다.