query-key-factory 라이브러리 도입에 관해서 2

[chasj0326]

저도 상훈님 아이디어에 많은 영감을 받아서 레이어를 하나 더 둬서 편리하게 하는 방법에 대해 생각해봤어요!
제가 가장 중요하게 여기는 요소는, useQuery 안에 써주는 쿼리 옵션들을 한방에 관리할 수 있느냐! 였습니다.
생각했던 방법들에 대해 써보겠습니다

1. 전부 custom 하기

// query-key-factory 역할을 하는 친구
import axios from 'axios';
import { UseQueryOptions } from '@tanstack/react-query';
import { ItemType } from '../types';

interface Query<T> {
  all: UseQueryOptions<T[]>;
  detail: (id: number) => UseQueryOptions<T>;
}

export const todo: Query<ItemType> = {
  all: {
    queryKey: ['todo-list'],
    queryFn: async () => {
      const { data } = await axios.get<ItemType[]>(
        `https://jsonplaceholder.typicode.com/todos`
      );
      return data;
    },
  },
  detail: (id: number) => ({
    queryKey: [id],
    queryFn: async () => {
      const { data } = await axios.get<ItemType>(
        `https://jsonplaceholder.typicode.com/todos/${id}`
      );
      return data;
    },
  }),
  retry: 2, // 다른 옵션도 한번에 작성
};

// 컴포넌트 사용 예시

const DataItem = ({ id }: DataItemProps) => {
  const { data: item, isSuccess } = useQuery<ItemType>({
    ...todo.detail(id),
  });
  // 생략

이런 방식으로 all 과 detail 이 있다는 가정 하에 .. UseQueryOptions 를 불러와서, 데이터 타입을 제네릭으로 넣어주는 식으로 하면 가능은 하더라구요 ..!
이렇게 직접 커스텀할 때, query-key-factory 라이브러리를 사용했을 때랑 비교하면 장단점이 있습니닷..

단점

• 모든 요청은 리스트와 아이템처럼 all 과 id 값을 받는 detail 로 이루어져야 하고, 다른 방식의 요청이 있다면 새로 타입을 추가해서 부여해주어야 합니다!
• query-key-factory 에서는 쿼리키에 대한 규칙들을 지원한다고 하더라구요? 커스텀하면 이것도.. 직접 하거나 넘어가야 한다는 단점이 있어요.
• 아래와 같이 쿼리 옵션들을 머지해서 한번에 부르는 게 가능할 지 모르겠네요!
  const queryKeys = mergeQueryKeys(comments, posts);
  아니면 모든 객체를 합치기 보다는 도메인 별로 가져가는 것도 호출할 때의 depth 를 낮추어서 좋을 것 같기도 합니다

장점

• 커스텀하게 되면, queryKey + queryFn 말고도 retry 와 같은 다른 옵션들도 한방에 관리할 수 있습니다!
• 사실 이 이유가 커스텀의 최대 장점이라고 생각해요

2. query-key-factory 사용 + 옵션만 커스텀

커스텀으로 완성할 수 없는 라이브러리의 장점들이 꽤 있어서,
라이브러리를 쓰면서 다른 옵션들을 한번에 관리하는 방법은 없을까에 대해 생각해 봤어요.
따라서 아래와 같이 가져가면 어떨까 합니다.

queryKey (queryKey, queryFn) = query-key-factory 로 관리하기
queryOptions (나머지 옵션들) = 커스텀하기

import { UseQueryOptions } from '@tanstack/react-query';

type QueryOption = Omit<UseQueryOptions, 'queryKey' | 'queryFn'>;
interface OptionMap {
  [target: string]: QueryOption;
}

export const todosOptions: OptionMap = {
  all: {
    retry: 0,
  },
  detail: {
    refetchOnMount: true,
  },
};

이런 식으로 query-key-factory 에서 관리하는 queryKey, queryFn 를 제외한 나머지 useQuery 옵션들을 따로 관리하는 방법입니다!
useQuery 를 사용할 때 useQuery({...todos.all, ...todosOptions.all}) 이렇게 쓰면 어떨까 해요

그치만 이 방법은 제가 지금 실험해보고 있는데 타입 에러가 나기에... 해결하고 다시 수정하겠습니다 ! 😭

빨리 공유해야 다른 분들이 생각하시는 데에 더 도움이 될 것 같아서 일단 올립니다 !

[bbearcookie]

우왕.. 쿼리 키와 관련해서 많은 고민을 하셨던게 느껴집니다!! 👍👍
공통적으로 사용되는 옵션도 함께 묶어서 정리하는 아이디어군요!! 😮

만약 앱에서 존재하는 Query의 대다수가 활용하는 옵션이라면, QueryClient를 생성할 때 defaultOptions를 부여하는 방법도 좋겠네요!! QueryClient

예를 들어 기본 설정으로는 네트워크 요청에 실패하면 3번까지 재시도를 하게 되는데 저는 최대 1의 값도 충분하다고 생각한다면:

import { QueryClient } from '@tanstack/react-query'

const queryClient = new QueryClient({
  defaultOptions: {
    queries: {
      retry: 1
    },
  },
})

요렇게 생성하면 원하는 속성의 기본 값을 지정해 줄 수 있는 것 처럼요!!
(실제 컴포넌트에서 쿼리를 사용할 때 원하는 속성값으로 오버라이딩도 가능)

[bbearcookie]

도메인 별로 옵션을 묶어서 정의하는 아이디어도 좋네요!! 👍👍
다만, 옵션이 쿼리에 의존하는 경우가 많을지 혹은 사용하려는 컴포넌트에 의존하는 경우가 많을지 고민되네요!!