8. 타입 안전한 React Query
타입스크립트를 사용하는건 좋은 생각이다. 타입 안전을 싫어하는 사람이 있을까?
버그를 미리 알 수 있고, 복잡한 앱의 구조를 타입으로 정의하여 그 부분들은 우리 머리 속에 담아둘 필요가 없어진다.
"타입을 선언"한 것과 "타입 안전"한 것은 큰 차이가 있다.
타입스크립트의 진정한 힘을 이용하려면 한 가지가 더 필요하다.
신뢰하기
우리는 타입 정의를 신뢰할 수 있어야한다.
그렇지 않으면 타입은 단순 제안에 불과하고, 정확하다고 믿을 수 없다.
- 가장 엄격한 타입스크립트 설정을 활성화하자.
- typescript-eslint를 추가하여 `any`타입과 `ts-ignore`를 금지하자.
- 타입 단언을 지양하자.
제네릭
타입스크립트에서 제네릭은 필수적이다.
조금이라도 복잡한 걸 구현하려면 제네릭을 사용해야할 것이다. (라이브러리)
하지만 라이브러리 사용자로서 이상적인 것은 제네릭에 대해서 신경쓰지 않는 것이다.
제네릭은 그저 구현 세부사항이다.
제네릭을 수동으로 작성하는 것은 두 가지 이유 중 하나로 인해 좋지 않다.
1. 사실 불필요하다.
2. 스스로를 속이고 있는 것이다.
꺾쇠괄호에 대해(<>)
꺾쇠괄호는 우리 코드를 더 복잡해 보이게 만든다.
예를 들어, 우리는 useQuery를 이렇게 사용하곤 한다
type Todo = { id: number; name: string; done: boolean }
const fetchTodo = async (id: number) => {
const response = await axios.get(`/todos/${id}`)
return response.data
}
const query = useQuery<Todo>({ // 제네릭으로 Todo 타입을 넣어주었다
queryKey: ['todos', id],
queryFn: fetchTodo,
})
query.data
// ^?(property) data: Todo | undefineduseQuery가 네 개의 제네릭을 가지고 있다는 것이 문제가 된다.
수동으로 하나만 제공하면 나머지 세 개는 기본값으로 돌아간다. 이게 왜 나쁜지는 #6: React Query and TypeScript에 나와있다.
`axios.get`은 any를 반환한다.(`fetch`도 마찬가지고, `ky`는 기본적으로 unknown을 반환한다)
`/todos/id`에서 무엇을 반환할지 모르고, data 속성도 any가 되길 원하지 않기 때문에 제네릭을 이용해 타입을 덮어써야한다.
하지만 더 나은 방법은 `fetchTodo` 함수 자체에 타입을 지정하는 것이다.
type Todo = { id: number; name: string; done: boolean }
// ✅ typing the return value of fetchTodo
const fetchTodo = async (id: number): Promise<Todo> => {
const response = await axios.get(`/todos/${id}`)
return response.data
}
// 또는 axios.get에 제네릭을 바로 제공할 수 있다.
const fetchTodo = async (id: number) => {
const response = await axios.get<Todo>(`/todos/${id}`)
return response.data
}
// ✅ no generics on useQuery
const query = useQuery({
queryKey: ['todos', id],
queryFn: () => fetchTodo(id),
})
// 🙌 types are still properly inferred
query.data
// ^?(property) data: Todo | undefined이제 React Query는 queryFn의 결과의 data가 무엇일지 제대로 추론할 수 있다.
제네릭의 중요 규칙
Effective TypeScript에서 언급되는 golden rule of Generics 이 있다.
For a Generic to be useful, it must appear at least twice.
(제네릭은 유용하다, 다만 적어도 두 번 이상 쓰일때만)
즉 "return-only" 제네릭은 타입 어설션과 다를게 없다는 뜻이다.
다음은 `axios.get`의 예시이다.
function get<T = any>(url: string): Promise<{ data: T, status: number}>제네릭 T가 리턴타입 Promise에만 사용되고 있다.
그럼 사실 이렇게 쓸 수도 있다.
const fetchTodo = async (id: number) => {
const response = await axios.get(`/todos/${id}`)
return response.data as Todo // type assertion
}적어도 타입 어셜션(`as Todo`)는 숨겨져 있지 않고 드러나있다.
다시, 신뢰하기
그리고 이제 다시 "신뢰"에 대해 생각해보자.
우리(프론트엔드)는 백엔드로부터 받는 정보가 실제로 그 타입인지 어떻게 믿을 수 있을까?
이 현상을 "신뢰 경계"라고 부르곤한다.
리턴 타입은 백엔드와 합의한 부분이기 때문에 믿고 작업할 수 밖에 없다.
만약 타입과 다른 데이터가 들어와서 문제가 생긴다면, 그건 우리(프론트엔드)의 문제가 아니다. - 문제는 백엔드 팀에게 있다.
물론 사용자는 신경쓰지 않는다.
그들은 단지 "cannot read property name of undefined"와 같은 에러 메시지를 볼 뿐이다.
프론트엔드 개발자로서 그 에러를 통해 백엔드로 부터 오는 데이터 타입이 잘못되었다는 사실을 알아채기는 꽤 오랜 시간이 걸린다.
그럼 백엔드에서 오는 데이터 타입에 대한 신뢰를 얻기위해 어떤 일을 할 수 있을까?
zod
zod는 런타임에 유효성 검사를 하는 스키마를 정의할 수 있는 검증 라이브러리이다.
또한 선언한 스키마로부터 타입을 추론(추출)할 수 있다.
타입을 선언한 다음, 데이터가 그 타입이라고 단언하는 대신
스키마를 작성하고 데이터가 그 스키마를 만족하는지 검증한다.
queryFn 내부에서 검증
import { z } from 'zod'
// 스키마 정의
const todoSchema = z.object({
id: z.number(),
name: z.string(),
done: z.boolean(),
})
const fetchTodo = async (id: number) => {
const response = await axios.get(`/todos/${id}`)
// 스키마를 이용해 데이터 파싱
return todoSchema.parse(response.data)
}
const query = useQuery({
queryKey: ['todos', id],
queryFn: () => fetchTodo(id),
})이전 코드와 비교해서 두 가지가 바뀌었다.
- Todo 타입 선언 -> todoSchema 스키마 선언
- 타입 단언 -> 스키마를 이용한 데이터 파싱
파싱(todoSchema.parse)에 문제가 생기면 zod에서 에러를 던진다.
그럼 우리는 그 에러를 처리해야하는 코드를 작성해야한다.
Tradeoffs
스키마 파싱은 데이터가 스키마와 일치하는지 런타임에 분석하기 때문에, 오버헤드가 발생한다.
따라서 이 방식을 모든 곳에 적용하는건 적절하지 않을 수 있다.
결론
useQuery의 제네릭을 쓰지 말고
queryFn에 넣을 fetch함수에 리턴 타입을 정의하자. (런타임에 타입 검증을 하고싶으면 zod를 쓰자)
더하여 queryOptions API를 함께 사용하면 queryClient.getQueryData와 같은 메서드의 리턴 타입 추론을 잘 할 수 있다.
이 글은 https://tkdodo.eu/blog/type-safe-react-query 를 번역 & 정리한 글입니다.