Request Waterfalls (요청폭포)가 발생할 수 있는 몇가지 예시를 설명하며, 해결방법을 제시합니다.

요청 폭포는 리소스(CODE, CSS, Image, DATA)에 대한 요청이 리소스에 대한 다른 요청이 완료될 때 까지 시작되지 않을 때 발생합니다.

Dependant Query (종속쿼리)

두 번째 쿼리에 enabled 옵션 설정으로 종속쿼리로 정의되어 있습니다. 첫 번째 쿼리가 실행 완료 후 두 번째 쿼리가 실행됩니다. -> 요청폭포 발생

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

import { axiosClient } from '../../api/apiClient';

const Dependant = () => {
  const { data: todoList, isFetched } = useQuery({
    queryKey: ['todo'],
    queryFn: () => axiosClient.get('https://jsonplaceholder.typicode.com/todos'),
  });
  const { data: postList } = useQuery({
    queryKey: ['posts'],
    queryFn: () => axiosClient.get('https://jsonplaceholder.typicode.com/posts'),
    enabled: isFetched,
  });

  return (
    <div style={{ display: 'flex' }}>
      <section>
        <h2>Todo List</h2>
        {todoList?.data.map(({ id, title }: { id: number; title: string }) => <div key={id}>{title}</div>)}
      </section>
      <section>
        <h2>Post List</h2>
        {postList?.data.map(({ id, title }: { id: number; title: string }) => <div key={id}>{title}</div>)}
      </section>
    </div>
  );
};
export default Dependant;

network waterfall이 생성되고있습니다. 따라서 서비스의 Loading이 길어지는 현상이 발생합니다.

useSuspenseQuery

Suspense와 함께 React 쿼리를 사용하는 경우 발생합니다.

// SuspenseQuery.ts
import { useQuery, useSuspenseQuery } from '@tanstack/react-query';

import { axiosClient } from '../../api/apiClient';

const SuspenseQuery = () => {
  const { data: todoList } = useSuspenseQuery({
    queryKey: ['todo'],
    queryFn: () => axiosClient.get('https://jsonplaceholder.typicode.com/todos'),
  });
  const { data: postList } = useSuspenseQuery({
    queryKey: ['posts'],
    queryFn: () => axiosClient.get('https://jsonplaceholder.typicode.com/posts'),
  });
  const { data: photoList } = useSuspenseQuery({
    queryKey: ['photo'],
    queryFn: () => axiosClient.get('https://jsonplaceholder.typicode.com/photos'),
  });
  const { data: userList } = useSuspenseQuery({
    queryKey: ['users'],
    queryFn: () => axiosClient.get('https://jsonplaceholder.typicode.com/users'),
  });

  return (
    <div style={{ display: 'flex' }}>
      <section>
        <h2>Todo List</h2>
        {todoList?.data.map(({ id, title }: { id: number; title: string }) => <div key={id}>{title}</div>)}
      </section>
      <section>
        <h2>Post List</h2>
        {postList?.data.map(({ id, title }: { id: number; title: string }) => <div key={id}>{title}</div>)}
      </section>
      <section>
        <h2>photo List</h2>
        {photoList?.data.map(({ id, title }: { id: number; title: string }) => <div key={id}>{title}</div>)}
      </section>
      <section>
        <h2>user List</h2>
        {userList?.data.map(({ id, title }: { id: number; title: string }) => <div key={id}>{title}</div>)}
      </section>
    </div>
  );
};
export default SuspenseQuery;

// QueryTest.tsx
import { Suspense } from 'react';
import SuspenseQuery from './SuspenseQuery';

const QueryTest = () => {
  return (
    <Suspense fallback={<div>...loading</div>}>
      <SuspenseQuery />
    </Suspense>
  );
};
export default QueryTest;

useSuspneseQueries 해결 방법

useSuspneseQueries 를 사용하면 간단하게 해결 할 수 있습니다.

// QueryTest.tsx
  const [todoList, postList, photoList, userList] = useSuspenseQueries({
    queries: [
      { queryKey: ['todo'], queryFn: () => axiosClient.get('https://jsonplaceholder.typicode.com/todos') },
      {
        queryKey: ['posts'],
        queryFn: () => axiosClient.get('https://jsonplaceholder.typicode.com/posts'),
      },
      {
        queryKey: ['photo'],
        queryFn: () => axiosClient.get('https://jsonplaceholder.typicode.com/photos'),
      },
      {
        queryKey: ['users'],
        queryFn: () => axiosClient.get('https://jsonplaceholder.typicode.com/users'),
      },
    ],
  });

network waterfall 해결되었습니다.

Nested Component Waterfalls

중첩 구성 요소 폭포는 상위 구성 요소와 하위 구성 요소 모두에 쿼리가 포함되어 있고 상위 구성 요소는 쿼리가 완료될 떄까지 하위 구성 요소를 _렌더링하지 않는 경우_입니다.

useQuery, useSuspenseQuery 모두 발생할 수 있습니다.

// User.tsx
import { useQuery, useSuspenseQuery } from '@tanstack/react-query';

import { axiosClient } from '../../api/apiClient';
import Comments from './Comments';

const Users = () => {
  const { data: userList, isPending } = useQuery({
    queryKey: ['users'],
    queryFn: () => axiosClient.get('https://jsonplaceholder.typicode.com/users'),
  });

  if (isPending) return <div>Loading....</div>;

  return (
    <div>
      <ul>
        {userList?.data.map((user: any) => {
          return <li key={user.id}>{user.name}</li>;
        })}
      </ul>
      <Comments postId={1}></Comments>
    </div>
  );
};
export default Users;

// Comments.tsx
import { useQuery } from '@tanstack/react-query';

import { axiosClient } from '../../api/apiClient';

const Comments = ({ postId }: { postId: number }) => {
  const { data: comments, isPending } = useQuery({
    queryKey: ['comments'],
    queryFn: () => axiosClient.get(`https://jsonplaceholder.typicode.com/comments?postId=${postId}`),
  });

  if (isPending) return <div>Loading....</div>;

  return <div>{comments?.data.id}</div>;
};
export default Comments;

Nested Component Waterfalls 해결방법

상위 항목에서 <User> 컴포넌트를 가져오는 동안 해당 ID는 렌더링 시 이미 사용 가능하므로 동시에 기사와 댓글을 가져올 수 없는 이유가 없습니다.

평탄화를 위해 상위 항목으로 끌어올려 해결 할 수 있습니다.

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

import { axiosClient } from '../../api/apiClient';
import Comments from './Comments';
import Users from './Users';

interface AnswerProps {
  postId?: number;
}

const Answer = ({ postId = 1 }: AnswerProps) => {
  const { data: commentsData, isPending: commentsPending } = useQuery({
    queryKey: ['comments'],
    queryFn: () => axiosClient.get(`https://jsonplaceholder.typicode.com/comments?postId=${postId}`),
  });

  const { data: usersData, isPending: usersPending } = useQuery({
    queryKey: ['users'],
    queryFn: () => axiosClient.get('https://jsonplaceholder.typicode.com/users'),
  });

  return (
    <>
      <Users usersData={usersData} />
      {commentsPending ? 'Loading comments...' : <Comments commentsData={commentsData} />}
    </>
  );
};
export default Answer;

useQueries 를 사용하여 두 쿼리를 하나로 결합하는 방식이 더 좋습니다.

import { useQueries, useQuery, useSuspenseQueries } from '@tanstack/react-query';

import { axiosClient } from '../../api/apiClient';
import Comments from './Comments';
import Users from './Users';

interface AnswerProps {
  postId?: number;
}

const Answer = ({ postId = 1 }: AnswerProps) => {
  const queryResults = useQueries({
    queries: [
      {
        queryKey: ['users'],
        queryFn: () => axiosClient.get('https://jsonplaceholder.typicode.com/users'),
      },
      {
        queryKey: ['comments'],
        queryFn: () => axiosClient.get(`https://jsonplaceholder.typicode.com/comments?postId=${postId}`),
      },
    ],
  });

  return (
    <>
      <Users usersData={queryResults[0].data} />
      <Comments commentsData={queryResults[1].data} />
    </>
  );
};
export default Answer;

몇 가지 상황을 제외하고 쿼리 여러 개가 선언된 일반적인 상황인 경우, 쿼리 함수들은 병렬로 요청되어 처리됩니다. 이런 특징은 쿼리 처리의 동시성을 극대화 시킵니다.

다중의 쿼리를 동시에 수행하는 경우, 렌더링이 거듭되는 사이에 계속 쿼리의 호출되어야 된다면 쿼리를 수행하는 로직이 hook 규칙에 어긋날 수도 있습니다. useQueries를 사용하여 해당 문제를 해결할 수 있습니다.

useQueries

useQueries

const getPosts = async (id: number) => {
  return await axios.get(`https://jsonplaceholder.typicode.com/post/{id}`);
};

const queryResults = useQueries({
  queries: [
    {
      queryKey: ["posts", 1],
      queryFn: () => getPosts(1),
      staleTime: Infinity,
    },
    {
      queryKey: ["posts", 2],
      queryFn: () => getPosts(2),
      staleTime: 0,
    },
    // ...
  ],
});

Queries Combine

Queries Combine 공식문서

useQueries hook이 반환한 모든 쿼리 결과가 포함된 배열을 단일 값으로 결합하여 사용하기 위해서는 combine 옵션을 사용하여 처리할 수 있습니다.

• combinedQueries는 data, pending 프로퍼티를 갖습니다.
  • 결합하면 쿼리 결과의 나머지 다른 프로퍼티들은 손실됩니다

const getPosts = async (id: number) => {
  return await axios.get(`https://jsonplaceholder.typicode.com/post/{id}`);
};

const ids = [1,2,3]
const combinedQueries = useQueries({
  queries: ids.map(id => (
    { queryKey: ['post', id], queryFn: () => getPosts(id) },
  )),
  combine: (results) => {
    return ({
      data: results.map(result => result.data),
      pending: results.some(result => result.isPending),
    })
  }
})

useQuery의 queryKey는 배열 로 지정해줘야 합니다. 문자열만 포함된 배열이 될 수도 있고, 여러 문자열과 중첩된 객체로 구성된 복잡한 형태일 수도 있습니다.

// An individual todo
useQuery({ queryKey: ['todo', 5], ... })

// An individual todo in a "preview" format
useQuery({ queryKey: ['todo', 5, { preview: true }], ...})


useQuery(['todos'], fetchTodos)

// 🚨 잘못된 사용 (query key 중복)
useInfiniteQuery(['todos'], fetchInfiniteTodos)

// ✅ 사용 가능
useInfiniteQuery(['infiniteTodos'], fetchInfiniteTodos)

• queryKey 를 기반으로 쿼리 캐싱을 관리하는 것이 핵심입니다.
• queryClient.setQueryData 등과 같은 특정 쿼리에 접근이 필요한 경우 초기 설정한 포맷을 지켜야 재대로 쿼리에 접근할 수 있습니다.

Query Key Factory

Query Key Factory

• typescript 지원
• 규칙성 있는 KEY 네이밍
• 모든 키는 직렬화 가능한 객체가 있는 키를 포함
• 간단하게 사용

표준화 된 키

직렬화 가능한 객체가 있는 키 포함, tanstack/query 규칙

import { createQueryKeys } from "@lukemorales/query-key-factory";

export const todos = createQueryKeys('todos', {
  detail: (todoId: string) => [todoId],
  list: (filters: TodoFilters) => ({
    queryKey: [{ filters }],
  }),
});

// => createQueryKeys output:
// {
//   _def: ['todos'],
//   detail: (todoId: string) => {
//     queryKey: ['todos', 'todo', todoId],
//   },
//   list: (filters: TodoFilters) => {
//     queryKey: ['todos', 'list', { filters }],
//   },
// }

종속적인 쿼리 선언

종속적이거나 상위 컨텍스트와 관련된 쿼리 선언을 할 수 있습니다.

export const users = createQueryKeys('users', {
  detail: (userId: string) => ({
    queryKey: [userId],
    queryFn: () => api.getUser(userId),
    contextQueries: {
      likes: {
        queryKey: null,
        queryFn: () => api.getUserLikes(userId),
      },
    },
  }),
});

// => createQueryKeys output:
// {
//   _def: ['users'],
//   detail: (userId: string) => {
//     queryKey: ['users', 'detail', userId],
//     queryFn: (ctx: QueryFunctionContext) => api.getUser(userId),
//     _ctx: {
//       likes: {
//         queryKey: ['users', 'detail, userId, 'likes'],
//         queryFn: (ctx: QueryFunctionContext) => api.getUserLikes(userId),
//       },
//     },
//   },
// }

export function useUserLikes(userId: string) {
  return useQuery(users.detail(userId)._ctx.likes);
};

간단한 KEY 접근

key 접근이 간단하여 캐시를 편리하게 관리하며, 무효화 할 수 있습니다.

users.detail({ status: 'completed' }).queryKey; // => ['users', 'detail', userId]
users.detail._def; // => ['users', 'detail']

편리한 타입 선언

import { mergeQueryKeys, inferQueryKeyStore } from "@lukemorales/query-key-factory";

import { users } from './users';
import { todos } from './todos';

export const queries = mergeQueryKeys(users, todos);

export type QueryKeys = inferQueryKeyStore<typeof queries>;

QueryFunctionContext 편리한 사용

전체 타입의 안정성을 확보하고 useQuery에 전달된 queryKey 에서 QueryFunctionContext 의 타입을 추론하는 것 입니다.

import type { QueryKeys } from "../queries";
// import type { TodosKeys } from "../queries/todos";

type TodosList = QueryKeys['todos']['list'];
// type TodosList = TodosKeys['list'];

const fetchTodos = async (ctx: QueryFunctionContext<TodosList['queryKey']>) => {
  const [, , { filters }] = ctx.queryKey;
  return api.getTodos({ filters, page: ctx.pageParam });
}

export function useTodos(filters: TodoFilters) {
  return useQuery({
    ...queries.todos.list(filters),
    queryFn: fetchTodos,
  });
};

쿼리가 자동으로 실행되지 않도록 설정할 수 있습니다. 보통 버튼 클릭이나 특정 이벤트를 통해 요청을 시도할 경우 같이 사용합니다.

• enabled : boolean
• false 설정하면 쿼리가 자동으로 실행되지 않습니다.
  • useQuery 반환 값 중 status가 pending 상태로 시작합니다.

enabled: false를 설정한 경우 queryClient가 쿼리를 다시 가져오는 방법 중 invalidateQueries 와 refetchQueries 를 무시합니다.

const getPosts = async () => {
  return await axios.get(`https://jsonplaceholder.typicode.com/posts`);
};

const usePosts = (enabled:boolean) => {
  return useQuery({
    queryKey: ["todo"],
    queryFn: getPosts,
    enabled: false,
  });
} 

const App = () => {
  const [enabled, setEnabled] = useState(false);
  const {data} = usePosts(enabled);
  const handleSearchPosts = () => {
    setEnabled(true);
  }

  return (
    <div>
      {data.map((body: string, idx: number) => (
        <div key={idx}>{body}</div>
      ))}
      <button onClick={handleSearchPosts}>조회하기</button>
    </div>
  );
}

select

• select : (data:TData) => unknown
• select 옵션을 사용하여 쿼리 함수에서 반환된 데이터의 일부를 변환하거나 선택할 수 있습니다.
• 반환된 데이터 값에는 영향을 주지만, ** 쿼리 캐시에 저장되는 내용에는 영향을 주지 않습니다.**

const getPosts = async () => {
  return await axios.get(`https://jsonplaceholder.typicode.com/posts`);
};

const usePosts = () => {
    return useQuery({
      queryKey: ["todo"],
      queryFn: getPosts,
      select: (data) => {
          return data.map((post: Data) => post.body);
      },
    });
}

const App = () => {
  const data = usePosts();
  return (
    <div>
      {data.map((body: string, idx: number) => (
        <div key={idx}>{body}</div>
      ))}
      <button onClick={handleSearchPosts}>조회하기</button>
    </div>
  );
}

placeholderData

• placeholderData: TData | (previousValue: TData | undefined; previousQuery: Query | undefined,) => TData
• placeholderData를 설정하면 쿼리가 pending 상태인 동안 특정 쿼리에 대한 placeholder data로 사용됩니다.
• placeholderData는 캐시에 유지되지 않으며, 서버 데이터와 관계 없는 보여주기용 가짜 데이터입니다.
• placeholderData에 함수를 제공하는 경우
  • 첫 번째 인자로 이전에 관찰된 쿼리 데이터를 수신
  • 두 번째 인자는 이전 쿼리 인스턴스

const getPosts = async () => {
  return await axios.get(`https://jsonplaceholder.typicode.com/posts`);
};

const usePosts = () => {
  const placeholderData = useMemo(() => getPosts(), []);
    return useQuery({
      queryKey: ["todo"],
      queryFn: getPosts,
      placeholderData: placeholderData,
    });
}

정의

atom의 값은 글로벌에 존재하는 atom 에 저장되는 것이 아닌 Context 와 비슷한 컴포넌트 트리 상에 저장됩니다.

Provider를 사용하면 atom 이 저장되는 Context 를 제공할 수 있습니다. ➡ 참조하는 Provider 가 다르면 같은 atom을 사용해도 값이 다릅니다.

• 초기값을 선언
• store 별로 업데이트 영역을 나누는 경우
• 개발 중 debug 정보 확인이 필요한 경우

const Root = () => (
  <Provider>
    <App />
  </Provider>
)

Provider 지정하지 않는다면 기본 저장소가 사용 됩니다. (provider-less mode)

const Root = () => (
    <App />
)

Store Prop

Provider 는 선택적으로 store 를 사용할 수 있습니다.

const myStore = createStore()

const Root = () => (
  <Provider store={myStore}>
    <App />
  </Provider>
)

next13 & Typescript 에서 Provider Store Test ➡ getServerSideProps 초기값 주입

import { Provider, WritableAtom, atom, createStore, useAtom } from "jotai";
import { useHydrateAtoms } from "jotai/utils";
import { NextApiRequest, NextApiResponse } from "next";

const countAtom = atom(0);
const myStore = createStore();

interface ProviderTestPropTypes {
  data: number;
}

type InitialValues = [WritableAtom<unknown, any[], any>, unknown][];

const ProviderTest = ({ data }: ProviderTestPropTypes) => {
  const initialValues = [[countAtom, data]] as InitialValues;

  useHydrateAtoms(initialValues, { store: myStore });
  useHydrateAtoms([[countAtom, 2]] as InitialValues);

  const [count, setCount] = useAtom(countAtom, { store: myStore });
  const [count2, setCount2] = useAtom(countAtom);

  return (
    <>
      <Provider store={myStore}>
        <div>테스트 : {count}</div>
        <button onClick={() => setCount((p) => p + 1)}>+1</button>
      </Provider>
      <Provider>
        <div>테스트2 : {count2}</div>
        <button onClick={() => setCount2((p) => p + 1)}>+1</button>
      </Provider>
    </>
  );
};

export default ProviderTest;

export const getServerSideProps = async (
  req: NextApiRequest,
  res: NextApiResponse
) => {
  const data = 77;
  return {
    props: {
      data,
    },
  };
};

Jotai v2 기준으로 작성되었습니다.

매핑된 타입은 한 객체가 또 다른 객체와 정확히 같은 속성을 가지게 할 때 이상적이다

const REQUIRES_UPDATE: { [k in keyof ScatterProps]: boolean } = {
  xs: true,
  ys: true,
  xRange: true,
  yRange: true,
  color: true,
  onClick: false,
};

function shouldUpdate(oldProps: ScatterProps, newProps: ScatterProps) {
  let k: keyof ScatterProps;
  for (k in oldProps) {
    if (oldProps[k] !== newProps[k] && REQUIRES_UPDATE[k]) {
      return true;
    }
  }
  return false;
}

typescript [k in keyof ScatterProps] 은 타입 체커에게 REQUIRES_UDPATE 가 ScatterProps 와 동일한 속성을 가져야한다는 정보를 제공합니다.

나중에 ScatterProps 에 새로운 속성을 추가하는 경우 다음 코드와 같은 형태가 됩니다.

interace ScatterProps {
  // ... Error onDoubleClick 속성이 타입에 없습니다.
  onDoubleClick: () => void;
}

이런 방식은 오류를 정확히 잡아 냅니다. 속성을 삭제하거나 이름을 바꾸어도 비슷한 오류가 발생합니다.

✅ 매핑된 타입을 사용해서 관련된 값과 타입을 동기화하도록 합시다. 인터페이스에 새로운 속성을 추가할 때, 선택을 강제하도록 매핑된 타입을 고려해야 합니다.

function arraySum (arr: readonly number[]) {
    let sum =0, num;
      while ((num = arr.pop()) !== undefined) {
        // readonly number[] 형식에 pop 속성이 없습니다.
          sum += num;
    }
      return sum;
}

readonly 는 몇가지 특성이 있습니다.

배열의 요소를 읽을 수 있지만, 쓸 수는 없습니다. length를 읽을 수 있지만, 바꿀 수는 없습니다.(배열을 변경함) 배열을 변경하는 pop을 비롯한 다른 메서드를 호출할 수 없습니다.

number[]는 readonly number[]보다 기능이 많기 때문에, readonly number[]의 서브타입이 됩니다. ➡ 변경 가능한 배열을 readonly 배열에 할당할 수 있지만, 그 반대는 불가능합니다.

const a: number[] = [1,2,3];
const b: readonly number[] = a;
const c: number[] = b; // error 할당 불가능

위의 arraySum 함수를 수정을 해보겠습니다.

function arraySum (arr: readonly number[]) {
    let sum =0, num;
      for (const num of arr) {
        sum += num;
    }
      return sum;
}

✅ 만약 함수가 매개변수를 변경하지 않는다면, readonly로 선언하자. 어떤 함수를 readonly로 만들면, 그 함수를 호출하는 다른 함수도 모두 readonly로 만들어야 한다.

readonly는 얕게(shallow) 동작합니다.

const dates: readonly Date[] = [new Date()];
dates.push(new Date());
// Error 'readonly Date[] 형식에 'push' 속성이 없습니다.

dates[0].setFullYear(2037);

현재 시점에는 깊은(deep) readonly 타입이 기본으로 지원되지 않지만, 제네릭을 만들면 깊은 readonly 타입을 사용할 수 있습니다. ➡ 제네릭은 만들기 까다롭기 때문에 ts-essentials DeepReadonly 제네릭 사용합니다.

인덱스 시그니처에 readonly 사용하기

인덱스 시그니처에도 readonly를 쓸 수 있습니다. 읽기는 허용하되 쓰기를 방지하는 효과가 있습니다.

let obj: {readonly [k:string]: number} = {};
// Readonly<{[k: string]: number}>

obj.hi =45; // Error ~ ...형식의 인덱스 시그니처는 읽기만 허용됩니다.
obj = {...obj, hi:12}; // 정상
obj = {...obj, bye: 34}; // 정상

자바스크립트에서 객체란 키/값 쌍의 모음이며, 값은 어떤 것이든 될 수 있습니다. 자바스크립트 엔진에서 object의 키는 string, symbol 타입만 가능합니다. ➡ 배열에서도 number 타입의 key로 접근이 불가능합니다.

하지만, 자바스크립트 엔진에서 자동으로 형변환이 되기에 number 타입의 키로도 접근이 가능합니다

array[0] -> array['0'] // 내부적으로 형변환이 됩니다.

const arr = [1, 2, 3]
console.log(Object.keys(arr)) // ['0', '1', '2']

인덱싱은 number 를 사용하지만 실제 배열의 key는 string 입니다.

타입스크립트는 일관성을 위해 number 타입의 키를 허용합니다.

인덱스 시그니처를 만들 때, 키 타입이 number 라면 거의 대부분 경우 이미 정의된 Array 나 튜플 , 또는 ArrayLike 타입을 통해 사용할 수 있습니다. ➡ ** number 인덱스 시그니처를 위해 새롭게 타입을 만들 일이 거의 없다는 뜻입니다.**

✅ 인덱스 시그니처에 number 를 사용하기 보다는 Array 나 튜플 , 또는 ArrayLike 타입을 사용하는 것이 좋습니다.

function checkedAccess<T>(xs: ArrayLike<T>, i: number): T {
  if ( i < xs.length) {
      return xs[i];
  }
  throw new Error('배열의 ...')
}

type Rocket = {[property: string]: string};
const rocket: Rocket = {
  name: 'Falcon 9',
  variant: 'v1.0',
  thrust: '4,940 kN',
}; 

인덱스 시그니처

[Property : string] : string

• 키의 이름 : 키의 위치만 표시, 타입 체커에서는 사용하지 않음
• 키의 타입 : string, number, symbol 조합, 보통 string을 사용합니다.
• 값의 타입 : 어떤 것이든 될 수 있습니다.

단점

• 잘못된 키를 포함해 모든 키를 허용 🚨 name 대신 Name으로 작성해도 유효한 Rocket 타입이 됩니다.
• 특정 키가 필요하지 않습니다. {}도 유효한 Rocket 타입입니다.
• 키마다 다른 타입을 가질 수 없습니다.
• 타입스크립트 언어 서비스는 도움이 되지 못합니다.
  • name: 을 입력할 때, 키는 무엇이든 가능하기 때문에 자동완성 기능이 동작하지 않습니다.

string 타입이 너무 광범위해서 인덱스 시그니처를 사용하는데 문제가 있습니다.

대안

Record를 사용하는 방법이 있습니다.

type Vec3D = Record<'x' | 'y' | 'z', number>;
/* Type Vec3D = {
    x: number;
    y: number;
    z: number;
*/

매핑을 사용합니다.

매핑된 타입은 키마다 별도의 타입을 사용하게 해줍니다.

type Vec3D = {[k in 'x' | 'y' | 'z']: number};
type ABC = {[k in 'a' | 'b' | 'c']: k extends 'b' ? string : number};
/* Type ABC = {
    a: number;
    b: string;
    c: number;
*/
}

type Tstate = {
  name: string;
  capital: string;
}

interface IState {
  name: string;
  capital: string;
}

대부분의 경우는 타입을 사용해도 되고 인터페이스를 사용해도 됩니다. 같은 상황에서는 동일한 방법으로 명명된타입을 정의해 일관성을 유지해야합니다.

타입을 I(인터페이스) 또는 T(타입)로 시작해 어떤 형태로 정의되었는지 나타냈지만 지양해야 할 스타일입니다. (C# 관례)

타입과 인터페이스의 공통점

추가 속성과 함께 할당하면 오류 발생합니다.

const wyoming: TState = {
  name: 'Wyoming',
  capital: 'Cheyenne',
  population:5 50000
};
// ..형식은 'TState' 형식에 할당할 수 없습니다. 
// 개체 리터럴은 알려진 속성만 지정할 수 있으며, 
// TState 형식에는 population이 없습니다.

인덱스 시그니처 인터페이스, 타입 모두 사용 가능합니다.

type TDict = { [key: string]: string};

interface IDict {
  [key: string]: string;
}

함수타입을 인터페이스나 타입으로 지정할 수 있습니다.

type TFn = (x: number) => string;
interface IFn {
  (x: number) :string;
}

type TFnWithProperties = {
  (x: number): number;
  prop: string;
}
interface IFnWithProperties {
  (x: number): number;
  prop: string;
}

인터페이스는 타입을 확장할 수 있으며, 타입은 인터페이스를 확장할 수 있습니다.

interface IStateWithPop extends TState {
    population: number;
}

type TStateWithPop = IState & { population: number }

🚨 인터페이스는 유니온 타입 같은 복잡한 타입을 확장하지는 못한다는 것입니다. ➡ 복잡한 타입을 확장하고 싶다면 타입과 &를 사용해야 합니다.

클래스 구현 시 사용가능합니다.

class StateT implements TState {
  name: string = '';
  capital: string = '';
}

class StateI implements IState {
  name: string = '';
  capital: string = '';
}

타입과 인터페이스의 차이점

타입

유니온 타입은 있지만 유니온 인터페이스라는 개념은 없습니다.

type AorB = 'a' | 'b';

인터페이스는 타입을 확장할 수 있지만, 유니온은 할 수 없습니다. ✅ 유니온 타입을 확장하는 게 필요할 때가 있습니다.

type Input = {/* ... */};
type Output = {/* ... */};
interface VariableMap {
  [name: string]: Input | Output;
}

이 타입은 인터페이스로 표현할 수 없습니다. type 키워드는 일반적으로 interface 보다 쓰임새가 많습니다.

type NamedVariable = (Input | Output) & {name: string}

type 키워드는 유니온이 될 수 있고, 매핑된 타입 또는 조건부 타입 같은 고급 기능에 활용 될 수 있습니다.

튜플, 배열 간결한 표현

튜플을 인터페이스로 구현해도, 튜플에서 사용할 수 있는 const 같은 매서드를 사용할 수 없기 때문에, 튜플은 type으로 구현하는게 좋습니다.

type Pair = [number, number];
type StringList = string[];
type NamedNums = [string, ...number[]];

interface Tuple {
  0: number;
  1: number;
  length: 2;
}

인터페이스

보강(augment) 가능합니다. ➡ 속성을 확장하는 것을 선언 병합이라고 합니다.

interface IState {
  name: string;
  capital: string;
}
interface IState {
  population: number;
}
const wyoming: IState = {
  name: 'Wyoming',
  capital: 'Cheyenne',
  population: 500_000
};

✅ 복잡한 타입이라면 타입 별칭을 사용하면 됩니다. 그러나 타입과 인터페이스, 두 가지 방법으로 모두 표현 할 수 있는 간단한 객체 타입이라면 일관성과 보강의 관점에서 고려해 봐야 합니다. 아직 스타일이 확립되지 않은 프로젝트라면, 향후 보강의 가능성이 있는지 확인이 필요합니다.

• 어떤 API에 대한 타입 선언을 작성해야 한다면 인터페이스를 사용하는 게 좋습니다. ➡ API가 변경될 때 사용자가 인터페이스를 통해 새로운 필드를 병합할 수 있어 유용합니다.

• 프로젝트 내부적으로 사용되는 타입에 선언 병합이 발생하는 것은 잘못된 설계입니다. ➡ 이런 경우 타입을 사용해야합니다.

함수의 문장 표현

function rollDice1(sides: number): number { /* ... */ }

함수 표현식

const rollDice2 = function(sides: number): number { /* ... */ }
const rollDice3 = (sides: number) : number => { /* ... */ }

타입스크립트에서는 함수 표현식을 사용하는 것이 좋습니다.

그 이유는 아래와 같이 정리할 수 있습니다.

• 함수의 매개변수, 반환값까지 전체를 함수 타입으로 선언하여 함수 표현식에 재사용할 수 있습니다.

type DiceRollFn = (sides: number) => number;
const rollDice: DiceRollFn = sides => {/* ... */}

• 함수 타입 선언을 이용하면 타입 구문을 적게 사용할 수 있으며,불필요한 코드의 반복을 줄일 수 있습니다.
• 함수 구현부가 분리되어 있어 로직을 분명하게 표현할 수 있습니다.

type BinaryFn = (a: number, b: number) => number;
const add: BinaryFn = (a, b) => a + b;
const sub: BinaryFn = (a, b) => a - b;
const mul: BinaryFn = (a, b) => a * b;

fetch 함수 응답 예제를 확인해보자.

• 정상적으로 데이터를 받는 경우 json
• 비 정상적인 데이터를 받는 경우 json 이 아닌 오류 메세지를 담은 rejected Promise를 반환합니다.

// lib.dom.d.ts에 다음과 같이 작성되어 있습니다.
declare function fetch(
 input: RequestInfo, init?: RequestInit
): Promise<Response>;

async function checkedFetc(input: RequestInfo, init?: RequestInit) {
  const response = await fetch(input, init);
  if (!response.ok) {
    // 비동기 함수 내에서 거절된 프로미스로 변환합니다.
    throw new Error('Request failed: ' + response.status);
  }
  return response;
}

간결하게 작성해보기

• 함수 표현식을 이용하여, 함수 전체에 타입을 적용 ➡ 타입스크립트가 자동으로 input 과 init 을 추론할 수 있게 해 줍니다.
• 타입 구문 또한 checkedFetch 의 반환데이터를 보장합니다.

const checkedFetch: typeof fetch = async (input, init) => {
  const response = await fetch(input, init);
  if (!response.ok) {
    throw new Error('Request failed: ' + response.status);
  }
  return response;
}

throw 대신 return을 사용했다면, 타입스크립트는 그 실수를 잡아냅니다.

const checkedFetch: typeof fetch = async (input, init) => {
  // Error 'Promise<Response | Error>' 형식은 Promise<Response> 형식에 할당할 수 없습니다.
  const response = await fetch(input, init);
  if (!response.ok) {
    return new Error('Request failed: ' + response.status);
  }
  return response;
}

✅ 함수의 매개변수에 타입 선언을 하는 것보다 함수 표현식 전체 타입을 정의하는 것이 코드도 간결하고 안전합니다.

타입스크립트에서는 변수에 값을 할당하고 타입을 부여하는 방법은 두가지입니다.

interface Person {name : string};
const alice : Person = {name : 'Alice'} //타입은 Person
const bob = {name : 'Bob'} as Person //타입은 Person

1. 타입 선언 : alice:Person
2. 타입 단언 : as Person

✅ 타입 단언보다 타입 선언을 사용하는 게 낫습니다.

const alice : Person = {
    name : 'Alice',
    occupation : 'TypeScript developer'
    // ~~~~ 개체 리터럴은 알려진 속성만 지정할 수 있으며
    // 'Person' 형식에 'occupation'이(가) 없습니다.
};
const bob = {
    name : 'Bob',
    occupation : 'JavaScript developer'
} as Person; // 오류 없음

타입 선언문에는 잉여 속성 체크 가 동작했지만, 단언문에는 적용되지 않습니다.

화살표 함수의 타입 선언은 추론된 타입이 모호할 때가 있습니다.

const people = ['alice', 'bob', 'jan'].map(name => ({name}));
// Person[]을 원했지만 결과는 {name : string;}[]...

타입 단언을 사용하면 문제가 해결되는 것처럼 보이지만, 런타임에 문제가 발생할 수 있습니다.

const people = ['alice', 'bob', 'jan'].map(name => ({name} as Person));
// 타입은 Person[]

// 런타임에서 문제가 발생할 수 있음
const people = ['alice', 'bob', 'jan'].map(name => ({} as Person));
// 오류없음

단언문을 사용하지 않고 화살표 함수 안에 타입과 함께 변수를 선언하는 것이 가장 직관적입니다.

const people = ['alice', 'bob', 'jan'].map(name => (
    const person:Person = {name};
    return person
)); // 타입은 Person[]

// 간결한 코드를 위해 변수 대신 화살표 함수의 반환 타입을 선언
const people = ['alice', 'bob', 'jan'].map(
    (name):Person => ({name})
); // 타입은 Person[]'

(name): Person 은 name에 타입이 없고 반환 타입이 Person 임을 명시합니다.

(name: Person) 은 name의 타입이 Person 임을 명시하고 반환 타입은 없기 때문에 오류가 발생합니다.

최종적으로 원하는 타입을 직접 명시하고, 타입스크립트가 할당문의 유효성 검사하게 합니다.

const people: Person[] = ['alice', 'bob', 'jan'].map(
    (name):Person => ({name})
); // 타입은 Person[]'

타입 단언이 꼭 필요한 경우

타입스크립트는 DOM에 접근할 수 없습니다. 자주쓰이는 특별한 문법(!)을 사용하여 null이 아님을 단언하는 경우도 있습니다.

const elNull = document.getElementById('foo'); //타입은 HTMLElement | null
const el = document.getElementById('foo'); //타입은 HTMLElement 

• 변수의 접두사로 쓰인 !는 boolean의 부정문입니다.
• 접미사로 쓰인 !는 그 값이 null이 아니라는 단언문으로 해석됩니다.

단언문은 컴파일 과정 중에 제거되므로, *타입 체커는 알지 못하지만 그 값이 null이 아니라고 확신할 수 있을때 사용해야 합니다. *

타입 단언문으로 임의의 타입 간에 변환을 할 수는 없습니다. A가 B의 부분집합인 경우에 타입 단언문을 사용해 변환할 수 있습니다.

➡ HTMLElement는 HTMLElement | null의 서브타입이기 때문에 이러한 타입 단언은 동작

interface Person { name: string; }
const body = document.body;
const el = body as Person;
// 형식이 충분히 겹치지 않기 때문에 실수로 판단, 의도적인 경우 먼저 식을 unknown으로 변환하세요.

const el = body as unknown as Person;

자바스크립트에서 타입스크립트로 index.ts 파일을 컴파일 하기 위해 tsc index.ts 를 사용합니다.

tsc 명령은 타입스크립트의 대부분 옵션을 -- 플래그로 사용할 수 있습니다. ➡ index.js 파일 생성을 건더뛰고 타입검사만 실행 (--noEmit 플래그 전달)

tsc index.ts --noEmit

tsc 구성 옵션 목록은 tsc --all 으로 확인 할 수 있습니다.

pretty 모드

tsc CLI는 색상과 간격의 스타일을 지정해 가독성을 높히는 pretty 모드 를 지원합니다. ➡ 기본적으로 pretty 모드로 설정됩니다.

tsc index.ts --pretty false 을 사용하여 타입스크립트에 더 간결하고 색상이 없는 형식을 사용하도록 지시할 수 있습니다.

watch 모드

watch 모드( -w, --watch )를 사용하면 종료하는 대신 타입스크립트를 무기한 실행 상태로 유지하고, 모든 오류의 실시간 목록을 가져와 터미널을 지속 업데이트 합니다. ➡ 여러 파일에 걸쳐서 리팩터링 같은 대규모 변경 작업을 할 때 유용함

tsc index.ts -w

TSConfig 파일 설정하기

대부분의 구성 옵션을 디렉터리의 tsconfig.json (TSConfig) 파일에 구체적으로 명시할 수 있습니다.

• tsconfig.json는 해당 디렉터리가 타입스크립트 프로젝트 루트임을 나타냅니다.
• 디렉터리에서 tsc 를 실행하면 해당 tsconfig.json 파일의 모든 구성 옵션을 읽습니다.

tsc 명령에 tsconfig.json 파일이 있는 디렉터리 경로 또는 tsc 가 tsconfig.json 대신 사용할 경로를 -p, --project 플래그에 전달하여 사용합니다.

tsc -p path/to/tsconfig.json

TSConfig 파일에서 사용 가능한 모든 구성옵션 목록은 [tsconfig.json] (https://www.typescriptlang.org/tsconfig) 참조하세요

tsconfig.json 생성하기

tsc 명령의 tsc --init 명령어를 사용합니다. ➡ 타입스크립트 프로젝트에서는 구성 파일을 생성하기 위해 해당 명령어를 사용하는 것을 권장합니다.

완전히 주석 처리된 tsconfig.json 파일이 생성됩니다.

{
    "compilerOptions": {
        //...
    }
}

Compiler Options

CLI와 TSConfig 파일에서 사용 가능한 대부분의 옵션은 다음 두 가지 범주 중 하나로 분류됩니다.

• 컴파일러 : 포함된 각 파일이 타입스크립트에 따라 컴파일 되거나 타입을 확인하는 방법
• 파일 : 타입스크립트가 실행될 파일과 실행되지 않은 파일

파일 포함 옵션

기본적으로 현재 디렉터리와 하위 디렉터리에 있는 숨겨지지 않은 모든 .ts 파일에서 실행되며, 숨겨진 디렉터리와 node_modules 디렉터리는 무시합니다. ✅ 타입스크립트 구성은 실행할 파일 목록을 수정할 수 있습니다.

include

파일을 포함하는 가장 흔한 방법으로 tsconfig.json 의 최상위 include 속성을 사용합니다. ➡ src/ 디렉터리 안의 모든 타입스크립트 소스 파일을 재귀적으로 포함합니다.

{
    "include": ["src"]
}

포함할 파일을 더 세밀하게 제어하기 위해 include 문자열에 글로브(glob) 와일드 카드를 허용합니다.

• *: 0 개이상의 문자와 일치합니다. (디렉터리 구분자 제외)
• ?: 하나의 문자와 일치합니다. (디렉터리 구분자 제외)
• **/ : 모든 레벨에 중첩된 모든 디렉터리와 일치합니다.

{
    "include": [
        "typings/**/*.d.ts",
          "src/**/*??.*"
    ]
}

다음 구성 파일은 typings/ 하위의 중첩된 디렉터리의 .d.ts 파일과 화강자 앞의 파일명에 적어도 두 개 이상의 문자를 가진 src/ 하위 파일만 허용합니다.

✅ 대부분 프로젝트는 ["src"] 와 같은 간단한 include 컴파일러 옵션만으로 충분합니다.

exclude

프로젝트의 include 파일 목록에 타입스크립트로 컴파일할 수 없는 파일이 포함되는 경우가 있습니다. ➡ TSConfig 파일의 최상위 exclude 속성에 경로를 지정하고 include 에서 경로를 생략합니다.

{
      "exclude" : ["**/external", "node_modules"], 
    "include" : ["src"]
}

exclude 는 include 의 시작 목록에서 파일을 제거하는 작업만 수행합니다. ✅ 타입스크립트는 비록 가져온 파일이 exclude 목록에 명시적으로 나열되어 있더라도 포함된 파일에 따라 가져온 모든 파일에서 실행됩니다.

대체 확장자

타입스크립트는 기본적으로 확장자가 .ts인 모든 파일을 읽을 수 있습니다. 그러나, 일부 프로젝트는 JSON 모듈 또는 리액트와 같은 JSX 구문 처럼 확장자가 다른 파일을 읽을 수 있어야 합니다.

JSX 구문

jsx

JSX 구문은 프리액트와 리액트 같은 UI 라이브러리에서 자주 사용합니다. 🟡 JSX 구문은 기술적으로 자바스크립트가 아닙니다. 🟢 자바스크립트로 컴파일 되는 자바스크립트 구문의 확장입니다.

JSX 구문을 사용하기 위해 두 가지를 수행합니다.

• 구성 옵션에서 jsx 컴파일러 옵션을 활성화
  • preserve (.jsx)
  • react (.js)
  • react-native (.js)
• .tsx 확장자로 파일 이름을 지정

{
      "compilerOptions" : {
        "jsx": "preserve"
    }
}

.tsx 파일의 제네릭 화살표 함수

제네릭 화살표 함수의 구문이 JSX 구문과 충돌합니다. ➡ .tsx 파일에서 화살표 함수에 대한 타입 인수 <T> 를 작성하면 T 요소의 시작 태그에 대한 종료 태그가 없기 때문에 구문 오류가 발생합니다.

const handleChange = <T>(input: T) => input;

구문의 모호성을 해결하기 위해 = unknown 제약 조건을 추가할 수 있습니다. ➡ 타입 인수 기본 값이 unknown 타입이므로 코드 동작이 전혀 반영되지 않습니다.

const handleChange = <T = unknown>(input: T) => input;

resolveJsonModule

resolveJsonModule 컴파일러 옵션을 true 로 설정하면 .json 파일을 읽을 수 있습니다. ➡ .json 파일을 마치 객체를 내보내는 .ts 파일인 것처럼 가져오며 객체의 타입을 const 변수 인 것처럼 유추합니다.

    import { user } from "./user.json";
    console.log(user);

esModuleInterop 컴파일러 옵션을 사용하면 기본 가져오기를 사용할 수 있습니다.

    import data from "./actvist.json";

array 또는 number 같은 다른 리터널 타입을 포함한 JSON 파일이라면 import 구문으로 * 사용합니다.

    // user.json
    [
        "SON",
          "JON",
          "LEE"
    ]

    // user.ts
    import * as users from "./actvist.json";
    console.log(users.length);

자바스크립트로 내보내기

바벨 같은 전용 컴파일러 도구 등장으로 타입스크립트 역할이 타입 검사만으로 축소되었지만, 여전히 타입스크립트에 의존하는 프로젝트도 많습니다.

outDir

기본적으로 타입스크립트 출력 파일은 해당 소스 파일과 동일한 위치에 생성합니다.

    users/
     user.js
     user.ts

🟢 경우에 따라 출력 파일을 다른 폴더에 생성하는 것이 더 나을 수 있습니다. tsc --outDir dist 명령어를 실행하면 dist/ 폴더에 출력 파일을 생성합니다.

    dist/
          users/
              user.js
    users/
     user.ts

✅ rootDir 컴파일러 옵션은 해당 루트 디렉터리를 명시적으로 지정하기 위해 존재하지만 . 또는 src 이외의 값을 사용할 일은 거의 없습니다.

target

타입스크립트는 자바스크립트 코드 구문을 지원하기 위해 어느 버전까지 변환해야 하는지를 지정하는 target 컴파일러 옵션을 제공합니다. 지정하지 않으면 이전 버전과 호환성을 위해 기본적으로 es3 이 지정됩니다.

• tsc --init 은 기본으로 es2016 을 지정하도록 설정되어 있습니다.

🟡 오래된 환경에서 최신 자바스크립트 기능을 지원하려면 더 많은 자바스크립트 코드를 생성해야 하므로, 파일 크기가 조금 더 커지고 런타임 성능이 조금 저하 됩니다.

✅ target 컴파일러 옵션은 코드가 실행될 수 있는 가장 오래된 환경의 값으로 지정하면 코드가 구문 오류 없이 여전히 실행 가능한 현대적이로 간결한 구문으로 내보내집니다.

내보내기 선언

declaration 컴파일러 옵션을 사용해 소스 파일에서 .d.ts 출력 파일을 내보냅니다.

{
      "compilerOptions" : {
        "declaration": true
    }
}

``.d.ts출력 파일은outDir옵션에 따라.js``` 파일과 동일한 출력 규칙에 따라 내보내집니다.

    users/
     user.d.ts
     user.js
     user.ts

emitDeclarationOnly

.js와 .jsx 파일 없이 선언 파일만 내보내도록 하는 emitDeclarationOnly 컴파일러 옵션이 존재합니다. ➡ 출력 선언 파일을 생성하려는 프로젝트에 유용합니다.

tsc --emitDeclarationOnly

{
      "compilerOptions" : {
        "emitDeclarationOnly": true
    }
}

    users/
     user.d.ts
     user.ts

소스 맵

소스 맵은 출력 파일의 내용이 원본 소스 파일과 어떻게 일치하는지에 대한 설명입니다. ➡ 브라우저 개발자 도구와 IDE에서 디버깅하는 동안 원본 소스 파일 내용을 볼 수 있도록 하는 시각적인 디버거에 특히 소스 맵이 유용합니다.

sourceMap

sourceMap 컴파일러 옵션을 사용하면 .js 또는 .jsx 출력 파일과 함께 .js.map 또는 .jsx.map 소스맵을 출력할 수 있습니다.

tsc --sourceMap

    users/
     user.js
     user.js.map
     user.ts

declarationMap

.d.ts 선언 파일에 대한 소스 맵을 생성할 수 있습니다.

tsc --declaration --declarationMap

    users/
     user.d.ts
     user.d.ts.map
     user.js
     user.ts

noEmit

파일 생성을 모두 건너뛰도록 지정할 수 있습니다. ➡ 어떤한 파일도 생성되지 않습니다. 타입스크립트는 발견한 구문 또는 타입 오류만을 보고합니다.

타입검사

타입스크립트 구성 옵션은 타입 검사기를 제어합니다.

lib

lib 컴파일러 옵션은 브라우저 타입 포함을 나타내는 dom 과 target 컴파일러 옵션을 기본값으로 하는 문자열 배열을 사용합니다. ➡ lib 설정을 변경하는 이유는 브라우저에서 실행되지 않는 프로젝트에서 기본으로 포함된 dom을 제거하기 위함입니다.

✅ 최신 자바스크립트 API를 지원하기 위해 폴리필 을 사용하는 프로젝트에서 lib 컴파일러 옵션을 사용해 dom과 특정 ECMA스크립트 특정 버전을 포함할 수 있습니다.

{
      "compilerOptions" : {
        "lib": ["dom", "es2020"]
    }
}

🔴 ES2020까지만 지원하는 플랫폼에서 실행되는 lib에서 String.replaceAll 과 같이 ES2021 이상에서 정의된 API를 사용하면 여전히 런타임 오류가 발생할 수 있습니다.

skipLibCheck

소스 코드에 명시적으로 포함되지 않은 선언 파일에서 타입 검사를 건너뛰도록 하는 skipLibCheck 컴파일러 옵션을 제공합니다. ➡ 공유된 라이브러리의 정의가 서로 다르고 충돌 할 수 있는 패키지 의존성을 많이 사용하는 애플리케이션에 유용합니다.

{
      "compilerOptions" : {
        "skipLibCheck": true
    }
}

✅ 타입 검사 일부를 건너뛰는 작업으로 타입스크립트 성능을 개선합니다. skipLibCheck 옵션을 활성화하는 것이 좋습니다.

엄격 모드

타입 검사 컴파일러 옵션은 대부분 strict mode 로 그룹화 됩니다. defalut : false

엄격 옵션 중에 noImplicitAny 와 stringNullChecks 는 타입 안전 코드를 적용하는데 특히 유용합니다.

특정 검사를 제외한 모든 엄격 모드를 활성화하고 싶다면 strict 활성화 특정 검사를 명시적으로 비활성화 할 수있습니다.

{
      "compilerOptions" : {
          "noImplicitAny" : false,
        "strict": true
    }
}

noImplicitAny

매개변수 또는 속성의 타입을 유추할 수 없는 경우는 any 타입으로 가정합니다. 🔴 대부분 우회할 수 있으므로 코드에서 이러한 암시적 타입은 허용하지 않는 것이 좋습니다.

const logMessage = (message) => {
    // Error : Parameter 'message' implicitly has an 'any' type
    console.log('Message: ${message}!');
}

const logMessage = (message:string) => {
    // OK
    console.log('Message: ${message}!');
}

strictBindCallApply

내장된 Function.apply, Function.bind, Function.call 함수 유틸리티를 나타낼 수 있을 만큼 충분한 타입 시스템 기능이 없었습니다. ➡ any를 사용해야 했음, 안정성과는 매우 거리가 먼 상태

function getLength(text:string, trim?: boolean) {
    return trim ? text.trim().length : text;
}
// (thisArg : typeof getLength, args: [text:string, trim?: boolean]) => number
getLength.apply;
// (trim?: boolean) => number
getLength.bind(undefined, "abc123");
// number
getLength.call(undefined, "abc123", true);

✅ strictBindCallApply 옵션을 활성화하는 것이 좋습니다. 프로젝트의 타입 안정성을 개선하는 데 도움이 됩니다.

strictFunctionTypes

함수 매개변수 타입을 약간 더 엄격하게 검사합니다. 매개변수가 다른 타입의 매개변수 하위 타입인 경우 함수 타입은 더 이상 다른 함수 타입에 할당 가능한 것으로 간주되지 않습니다.

function checkOnNumber(containsA: (input: number | string) => boolean) {
    return containsA(1337);
}

function stringContainsA(input:string) {
    return !!input.match(/a/i);
}

checkOnNumber(stringContainsA);

checkOnNumber 함수는 number | string 을 받는 함수를 사용해야 하지만, 오직 타입이 string인 매개변수만 받을 것 으로 예상하는 stringContainsA 함수 제공

stringContainsA 함수가 제공되는 것을 허용하고, 프로그램은 매개 변수가 number인 경우 .match() 를 호출하려고 하면 문제가 발생합니다.

strictNullChecks

strictNullChecks 플래그를 비활성화하면 코드의 모든 타입에 null | undefined 가 추가되고, ➡ 모든 변수가 null 또는 undefined를 받을 수 있도록 허용합니다.

strictNullChecks 활성화 한경우, string 타입인 value에 null을 할당하면 타입 오류가 발생합니다.

let value : string;

value = "abc1234"; // OK
value = null; // ERROR

✅ strictNullChecks 옵션을 활성화하는 것이 좋습니다. 충돌을 방지할 수 있습니다.

strictPropertyInitialization

플래그는 초기화가 없고, 생성자에게 확실하게 할당되지 않은 클래스 속성에서 타입 오류를 발생합니다.

class Animal {
  private name: string; // error
  // 'name' is declared but its value is never
}

class Animal {
  private name: string;
  constructor(name: string) { // OK
    this.name = name;
  }
}

✅ strictPropertyInitialization 옵션을 활성화하는 것이 좋습니다. 클래스 초기화 로직 실수로 인한 충돌을 방지할 수 있습니다.

useUnknownInCatchVariables

catch 문에 error 변수의 타입을 변경할 수 있는 옵션 true : unknown false : any

try {
    someExternalFunction()
} catch (error) {
    error; // 기본 타입 : any
}

any 사용과 마찬가지로 오류를 억지로 명시적 타입 어서션 또는 내로잉 하는 비용보다 unknown 으로 처리하는 것이 기술적으로 더 타당합니다.

try {
    someExternalFunction()
} catch (error : unknown) {
    error; // 기본 타입 : unknown
}

모듈

새로운 타입스크립트 프로젝트는 대부분 표준화된 ECMA스크립트 모듈 구문으로 작성됩니다.

import { value } from "my-example-value";

export const logValue = () => console.log(value);

module

어떤 모듈 시스템으로 변환된 코드를 사용할지 결정하기 위해 module 컴파일러 옵션을 제공합니다. module 값에 따라 export와 import 문을 다른 모듈 시스템으로 변환할 수 있습니다.

{
      "compilerOptions" : {
          "module" : "commonjs"
    }
}

const my_example_lib = require("my-example-value");

export const logValue = () => console.log(my-example-value);

target 컴파일러 옵션이 es3 또는 es5 인 경우 module 컴파일러 옵션의 기본값은 commonjs 가 됩니다.

그렇지 않다면 ECMA스크립트 모듈로 출력하도록 지정하기 위해 module 컴파일러 옵션은 es2015 로 기본 설정됩니다.

moduleResolution

모듈 해석은 import에서 가져온 경로가 module에 매핑되는 과정입니다.

• node : 기존 Node.js 와 같은 CommonJS 리졸버 에서 사용하는 동작
• nodenext : ECMA스크립트 모듈에 대해 지정된 동작에 맞게 조정

🟡 두 전략은 유사하며, 차이를 느끼지 못합니다.

{
      "compilerOptions" : {
          "moduleResolution" : "nodenext"
    }
}

CommonJs와의 상호 운용성

자바스크립트 모듈로 작업할 때 모듈의 기본 내보내기와 네임스페이스 출력 간에는 차이점이 있습니다.

• 모듈의 기본 내보내기 : 내보낸 객체의 .default 속성
• 모듈의 네임스페이스 내보내기 : 내보낸 객체 자체

🟡 대부분의 프로젝트 처럼 npm 패키지에 의존하는 경우 의존성 중 일부는 여전히 CommonJS 모듈로 배포됩니다.

esModuleInterop

module 이 es2015 또는 esnext 와 같은 ECMA스크립트 모듈 형식이 아닌 경우 타입스크립트에서 내보낸 자바스크립트 코드에 소량의 로직을 추가합니다.

✅ 기본 내보내기를 제공하지 않는 react 같은 패키지를 위해서입니다.

➡ esModuleInterop 은 내보낸 자바스크립트 코드가 가져오기로 작동하는 방식에 대해서만 직접 변경합니다.

allowSyntheticDefaultImports

ECMA스크립트 모듈이 호환되지 않는 CommonJS 네임스페이스 내보내기 파일에서 기본 가져오기를 할 수 있음을 타입 시스템에 알립니다.

allowSyntheticDefaultImports 컴파일러 옵션은 다음 중 하나가 true 인 경우에만 true 로 기본적 설정됩니다.

• module이 system인 경우
• esModuleInterop : true, module 이 es2015 또는 esnext 와 같은 ECMA스크립트 모듈 형식이 아닌 경우

➡ esModuleInterop : true 이지만 module : esnext 경우 타입스크립트는 컴파일된 출력 자바스크립트 코드가 가져오기 상호 운용성 지원을 사용하지 않는다고 가정합니다.

import React from "react"; 
// ERROR
// default-imported using the `allowSyntheticDefaultImports flag`

isolatedModules

한 번에 하나의 파일에서만 작동하는 바벨과 같은 외부 트랜스파일러는 타입 시스템 정보를 사용해 자바스크립트를 내보낼 수 없습니다.

{
      "compilerOptions" : {
          "isolatedModules" : true
    }
}

✅ 프로젝트에서 타입스크립트가 아닌 다른 도구를 사용해 자바스크립트로 변환하는 경우 isolatedModules를 활성화 하는 것이 좋습니다.

자바스크립트

타입스크립트는 기본적으로 .js , .jsx 확장자를 가진 파일을 무시하지만 allowJs 와 checkJs 컴파일러 옵션을 사용하면 자바스크립트 파일을 읽고, 컴파일하고, 제한된 기능이지만 타입 검사도 할 수 있습니다.

allowJs

자바스크립트 파일에 선언된 구문을 타입스크립트 파일에서 타입 검사를 하도록 허용합니다. jsx 컴파일러 옵션과 결합하면 .jsx 파일도 검사할 수 있습니다.

import { value } from "./values";
console.log('Quote: '${value.toUpperCase()}'');

🟡 allowJs 가 활성화 되지않으면import 문은 알려진 타입을 갖지 못합니다. 기본적으로 암시적 any가 되거나 타입오류가 발생합니다.

allowJs 는 ECMA스크립트 target에 맞게 컴파일되고 자바스크립트로 내보내진 파일목록에 자바스크립트 파일을 추가합니다. 활성화 된 경우 소스 맵과 선언 파일도 생성됩니다.

{
      "compilerOptions" : {
          "allowJs" : true
    }
}

✅ allowJs 가 활성화되면 가져온 value는 string 타입이 되며 오류도 발생하지 않습니다.

checkJs

자바스크립트 파일도 타입 검사가 가능합니다.

• allowJs 옵션이 아직 true 가 아니라면 기본값을 true 로 설정하기
• .js 와 .jsx 파일에서 타입 검사기 활성화 하기

{
      "compilerOptions" : {
          "checkJs" : true
    }
}

✅ checkJs 를 활성화하면 타입 스크립트가 자바스크립트 파일을 타입스크립트 관련 구문이 없는 타입스크립트 파일인 것 처럼 처리합니다. 타입 불일치, 철자가 틀린 변수명 등 타입스크립트 파일에서 일반적으로 발생하는 모든 오류를 발생시킬 수 있습니다.

// index.js
let myQuote = "Each person...";
console.log(quote); // Error

🔴 checkJs 가 활성화되지 않았다면 타입스크립트는 해당 버그에 대한 오류를 보고하지 않습니다.

@ts-check

파일 상단에 // @ts-check 주석을 사용해 파일별로 checkJs 를 활성화 합니다.

// index.js
// @ts-check
let myQuote = "Each person...";
console.log(quote); // Error

JSDoc 지원

allowJs 와 checkJs 가 활성화되면 타입스크립트는 코드의 모든 JSDoc 정의를 인식합니다.

// index.js

/**
/* @param {string} text
*/
function sentenceCase(text) {
    return '${text[0].toUpperCase()} ${text.slice(1)}.';
}

sentenceCase("hello world"); // Ok
sentenceCase(["hello", "world"]); // ERROR

구성 확장

TSConfig 파일이 다른 구성 파일에서 구성 값을 확장(extend) 하거나 복사하도록 선택하는 메커니즘을 제공합니다.

extends

extends 구성 옵션을 사용해 다른 TSConfig에서 확장할 수 있습니다. extends는 다른 TSConfig 파일에 대한 경로를 가져오고 해당 파일의 모든 설정을 복사해야 함 을 나냅니다.

파생 또는 자식 구성에서 선언된 모든 옵션은 기본 또는 부모 구성에서 동일한 이름의 모든 옵션을 다시 정의합니다.

packages/* 디렉터리를 포함하는 모노레포(monorepo) 처럼 여러 개의 TSConfig가 있는 많은 저장소는 규칙에 따라 확장할 tsconfig.json 파일에 대한 tsconfig.base.json 파일을 생성합니다.

// tsconfig.base.json
{
      "compilerOptions" : {
          "strict" : true
    }
}

// packages/core/tsconfig.json
{
      "extends": "../../tsconfig.base.json",
    "includes": ["src"]
}

compilerOptions 는 재귀적으로 고려됩니다. 파생된 TSConfig에서 특정 옵션을 재정의하지 않는 한 기본 TSConfig의 각 컴파일러 옵션은 파생된 TSConfig로 그대로 복사됩니다.

// packages/js/tsconfig.json
{
      "extends": "../../tsconfig.base.json",
    "compilerOptions" : {
        "allowJs" : true
    }
    "includes": ["src"]
}

확장 모듈

extends 속성은 다음 자바스크립트 가져오기 중 하나를 사용합니다.

• 절대 경로 : @ 또는 알파벳 문자로 시작
• 상대 경로 : 마침표(.)로 시작하는 로컬 파일 경로

extends 값이 절대 경로라면 npm 모듈에서 TSConfig를 확장함을 나타냅니다. 타입스크립트는 이름과 일치하는 패키지를 찾기 위해 일반 노드 모듈 확인 시스템을 사용합니다.

✅ 많은 조직에서 npm 패키지를 사용해 여러 저장소 또는 모노레포 내에서 타입스크립트 컴파일 옵션을 표준화 합니다.

// packages/tsconfig.json
{
      "compilerOptions" : {
          "strict" : true
    }
}

// packages/js/tsconfig.json
{
      "extends": "@my-org/tsconfig",
    "compilerOptions" : {
          "allowJs" : true
    }
    "includes": ["src"]
}

// packages/ts/tsconfig.json
{
      "extends": "@my-org/tsconfig",
    "includes": ["src"]
}

구성 베이스

처음 부터 고유한 구성을 생성하거나 --init 제안을 하는 대신, 특정 런타임 환경에 맞게 미리 만들어진 베이스 TSConfig 파일로 시작할 수 있습니다.

디노에서 권장되는 TSConfig 베이스를 설치하려면 다음과 같이 진행합니다.

npm install --save-dev @tsconfig/deno
# or
yarn add --dev @tsconfig/deno

구성 패키지가 설치되고 나면 다른 npm 패키지 구성 확장처럼 참조할 수 있습니다.

// packages/js/tsconfig.json
{
      "extends": "@tsconfig/deno/tsconfig.json",
}

프로젝트 레퍼런스

대규모 프로젝트에서 프로젝트의 서로 다른 영역에 서로 다른 구성 파일을 사용하는 것이 유용할 수 있습니다. ✅ 타입스크립트에서는 여러 개의 프로젝트를 함께 빌드하는 프로젝트 레퍼런스 시스템을 정의할 수 있습니다.

단일 TSConfig 파일을 사용하는 것보다 조금 더 작업이 많지만 몇 가지 핵심 이점이 있습니다.

• 특정 코드 영역에 대해 다른 컴파일러 옵션을 지정할 수 있습니다.
• 개별 프로젝트에 대한 빌드 출력을 캐시할 수 있으므로 종종 대규모 프로젝트의 빌드 시간이 훨씬 빨라집니다.
• 프로젝트 레퍼런스는 코드의 개별 영역을 구조화하는데 유용한 의존성 트리(특정 프로젝트가 다른 프로젝트에서 파일을 가져오는 것만 허용)를 실행합니다.

composite

composite 구성 옵션을 선택해 파일 시스템 입력과 출력이 제약 조건을 준수함을 나타냅니다.

composite : true 일 때는 다음과 같습니다.

• rootDir 설정이 아직 명시적으로 설정되지 않았다면 기본적으로 TSConfig 파일이 포함된 디렉토리로 설정됩니다.
• 모든 구현 파일은 포함된 패턴과 일치하거나 파일 배열에 나열되어야 합니다.
• declaration 컴파일 옵션은 반드시 true 여야 합ㄴ디ㅏ.

// core/tsconfig.json
{
    "compilerOptions" : {
        "declaration" : true
    }
    "composite" : true
}

✅ 타입스크립트가 프로젝트에 대한 모든 입력 파일과 일치하는 .d.ts 파일을 생성하도록 강제할 때 유용합니다. composite 옵션은 다음 refernces 구성 옵션과 함께 사용할 때 가장 유용합니다.

references

참조된 프로젝트에서 모듈을 가져오는 것은 출력 .d.ts 선언 파일에서 가져오는 것으로 타입 시스템에 표시됩니다.

다음 구성 스니펫은 core/ 디렉터리를 입력으로 참조하도록 shell/ 디렉터리를 설정합니다.

// shell/tsconfig.json
{
   "refernces" : [
     { "path" : "../core" }
   ]
}

💡 references 구성 옵션은 기본 TSConfig에서 extends를 통해 파생된 TSConfig로 복사되지 않습니다.

references 옵션은 다음 빌드 모드와 함께 사용할 때 가장 유용합니다.

빌드 모드

코드 영역이 프로젝트 레퍼런스를 사용하도록 한번 설정되면 빌드(build) 모드에서 -b 또는 --b CLI 플래그를 통해 tsc를 사용할 수 있습니다.

• TSConfig의 참조된 프로젝트를 찾습니다.
• 최신 상태를 감지합니다.
• 오래된 프로젝트를 올바른 순서로 빌드합니다.
• 재공된 TSConfig 또는 TSConfig의 의존성이 변경된 경우 빌드합니다.

✅ 타입스크립트 빌드 모드 기능은 최신 프로젝트를 다시 빌드하는 것을 건너뛰도록 해 빌드 성능을 크게 향상시킵니다.

코디네이터 구성

저장소에서 타입스크립트 프로젝트 레퍼런스를 설정하는 편리한 방법은 빈 파일 배열과 저장소의 모든 프로젝트 레퍼런스에 대한 레퍼런스를 사용해 최상위 레벨의 tsconfig.josn을 설정하는 것입니다.

최상위 TSConfig는 타입스크립트가 파일 자체를 빌드하도록 지시하지 않습니다. ➡ 필요에 따라 참조된 프로젝트를 빌드하도록 타입스크립트에 알리려는 역할만 합니다.

다음은 tsconfig.json은 저장소의 packages/core 와 packages/shell 프로젝트를 빌드하는 것을 나타냅니다.

// tsconfig.json
{
   "files": [],
   "refernces" : [
     { "path" : "./packages/core" },
     { "path" : "./pacakages/shell" },
   ]
}

빌드 옵션 모드

빌드 모드는 몇 가지 빌드에 특화된 CLI 옵션을 지원합니다.

• --clean : 지정된 프로젝트의 출력을 삭제합니다 (--dry 함께 사용할 수 있습니다.)
• --dry : 수행할 작업을 보여주지만 실제로 아무것도 빌드하지 않습니다.
• --force : 모든 프로젝트가 오래된 것처럼 작동합니다.
• -w or --watch : 일반적인 타입스크립트 watch 모드와 유사합니다.

✅ 빌드 모드는 watch 모드를 지원하기 때문에 tsc b -w 같은 명령을 실행하면 대규모 프로젝트에서 모든 컴파일러 오류에 대한 최신 목록을 빠르게 확인 할 수 있습니다.

Pagination 은 useQuery 와 prefetchQuery 를 사용하면 다음 페이지로 이동할 때 이미 다음 페이지의 데이터를 캐시하고 있어, 사용자가 대기하는 시간 없이 바로 화면에 렌더링 할 수 있는 좋은 기법이다.

keepPreviousData 옵션 활성화

keepPreviousData 옵션을 true 로 설정한 경우, 새로운 데이터가 요청되는 동안 성공적으로 가져온 마지막 데이터를 화면에 유지시켜준다. ➡ 유저의 입장에서 화면이 일관성 있게 유지되며 데이터만 변경되기 때문에 자연스러운 UI를 볼 수 있다.

  const queryInfo = useQuery(
    queries.posts.getPosts(page, limit).queryKey,
    getPostsApi,
    {
      staleTime: 5000, // fetch된 데이터 5초간 fresh 상태
      keepPreviousData: true, // 쿼리 키가 변경되어도 이전 데이터를 유지
    },
  );

PrefetchQuery 사용하기

prefetchQuery 은 이전 글을 참고하자 React-Query PrefetchQuery

useEffect(() => {
    if (data?.hasMore) {
      queryClient.prefetchQuery(["projects", page + 1], () =>
        fetchProjects(page + 1)
      );
    }
  }, [data, page, queryClient]);

page가 변경될 때 다음 데이터가 존재하는 경우 다음 페이지의 데이터를 prefetchQuery 통해 프리 패칭하여 캐시에 저장한다.

참고 : React-Query pagination

pre+fetch 의 합성어 사용자가 데이터가 필요하기 전에 보여줄 데이터를 미리 가져올 수 있도록 알 수 있습니다.

주로 server side 에서 데이터를 미리 받아오거나, 화면 전환시 컴포넌트 마운트 전에 데이터를 미리 받아오기 위해 사용합니다.

prefetchQuery method를 사용하여 캐시에 넣을 쿼리 결과를 미리 가져 올 수 있습니다. ➡ loading 없이 바로 임시 데이터를 보여줄 수 있습니다.

사용자에게 편리한 UX를 보여줄 수 있다!

const getPostsApi = async (
  ctx: QueryFunctionContext<getPostListQuery["queryKey"]>,
): Promise<Post[]> => {
  const [, , { page, limit }] = ctx.queryKey;
  const response = await axiosClient.get<Post[]>(
    `${BASE_URL}/posts`,
    {
      params: { page: page, limit: limit },
    },
  );
  return response.data;
};


const prefetchTodos = async () => {
  const queryClient = useQueryClient();
  // ✅ The results of this query will be cached like a normal query
  await queryClient.prefetchQuery(
    queries.posts.getPosts(page, limit).queryKey
    getPostsApi,
  )
}

• 쿼리에 대한 데이터가 이미 캐시에 있으며, 무효화되지 않는 경우 데이터를 가져오지 않습니다. ➡ 지정된 staleTime 보다 오래된 경우 쿼리를 가져 옵니다.

  const prefetchTodos = async () => {  
  const queryClient = useQueryClient();
  await queryClient.prefetchQuery(
    queries.posts.getPosts(page, limit).queryKey
    getPostsApi,
    {
        staleTime: 5000
    }
  )
  }

• useQuery prefetch 된 쿼리에 대한 인스턴스가 없다면, 지정된 시간 이후 삭제되어 가비지에 수집됩니다.

mutations 은 부과 효과(side effect) 함수 입니다. react query로 서버 상태를 관리하기 때문에 mutations 은 서버에 부가 효과를 일으킬 수 있습니다.

Similarities to useQuery

useMutation 은 useQuery 가 쿼리에 대해 수행하는 것처럼 mutation 의 상태를 추적합니다.

loading , error, status fields 를 제공하여 무슨 상태인지 알 수 있습니다.

Differences to useQuery

대부분의 쿼리는 자동으로 실행됩니다.

• mutations 의 경우 자동으로 실행되지 않습니다.
• mutations 가 useQuery 처럼 상태를 공유하지 않습니다.
• 컴포넌트에서 useQuery 를 여러 번 호출 할 수 있으며 캐시된 결과를 동일하게 반환하지만 mutations 은 동작하지 않습니다.

Tying mutations to queries

mutation 은 대부분 쿼리에 직접 연결되지 않게 설계합니다. mutation 이 쿼리에 대한 변경 사항을 반영하기 위해 두 가지 방법이 있습니다.

Invalidation (무효화)

화면을 최신 상태로 만드는 가장 간단한 방법입니다. react query가 현재 사용 중인 경우 해당 데이터를 다시 가져오며, 가져오기가 완료되면 화면이 자동으로 업데이트 됩니다. ➡ 무효화할 쿼리만 라이브러리에 알려주면 됩니다.

💡 queryClient.invalidateQueries(queryKey) 를 통해 캐시를 무효화 할 수 있습니다.

const useUpdatePostMutation = (postId: number) => {
  const queryClient = useQueryClient();
  return useMutation({
    mutationFn: ({
      postId,
      title,
      body,
    }: {
      postId: number;
      title: string;
      body: string;
    }) => {
      return updatePostDetailApi(postId, title, body);
    },
    onSuccess: (newPost) => {
      // ✅ refetch the comments list for our blog post
      queryClient.invalidateQueries(queries.posts.detail(postId).queryKey);

    },
  });
};

Direct updates

mutation 가 알아야 할 모든 정보를 반환하는 경우 데이터를 다시 검색할 필요가 없습니다.

💡 setQueryData 를 통해 직접 쿼리 캐시를 업데이트 할 수 있습니다.

const useUpdatePostMutation = (postId: number) => {
  const queryClient = useQueryClient();
  return useMutation({
    mutationFn: ({
      postId,
      title,
      body,
    }: {
      postId: number;
      title: string;
      body: string;
    }) => {
      return updatePostDetailApi(postId, title, body);
    },
    onSuccess: (newPost) => {
      // ✅ update detail view directly
      queryClient.setQueryData(queries.posts.detail(postId).queryKey, newPost);
    },
  });
};

setQueryData 를 통해 직접 캐시에 데이터를 주입하면 데이터가 백엔드에서 반환된 것 처럼 동작합니다. ➡ 해당 쿼리를 사용하는 모든 컴포넌트가 다시 렌더링되는 것을 뜻합니다.

🤟 대부분 무효가 선호되는 것이 안전한 접근법 이라고 생각합니다.

Optimistic updates (낙관적 업데이트)

useQuery 캐시는 쿼리 간 전환 시, prefetching 과 결합할 때 데이터를 즉시 제공합니다. ➡ 전체적인 UI가 매우 빠르게 느껴집니다. mutations 도 같은 이 점을 어떻게 얻을 수 있을까요?

낙관적인 업데이트는 서버에 전송하기도 전에 mutations 의 성공을 가장합니다.

1. 성공적인 응답을 받음
2. 실제 데이터를 보기 위해 무효화 처리
3. 요청이 실패하면 UI를 변환 전 상태로 롤백 처리

언제 사용 할까?

구체적인 예시는 공식 문서에 정리되어 있습니다. ( typescript example )

낙관적 업데이트는 정말 필요할 때 사용해 주세요 ➡ UX를 실제로 나쁘게 만들 수 있으며, 로딩 애니메이션을 보여주는 것이 더 효율적일 수 있습니다.

Common Gotchas

확실하지 않을 수 있는 mutations 을 사용할 때 몇 가지 좋은 사항에 대해서 알아봅시다.

awaited Promises

mutation 콜백에서 반환된 Promise는 react query에 의해 대기(awaited)되며, 실제로 invalidateQueries 는 Promise를 반환합니다. ➡ 관련 쿼리가 업데이트되는 동안 변환을 loading 상태로 유지하려면 콜백에서 invalidateQueries 의 결과를 반환해야 합니다.

{
  // 🎉 will wait for query invalidation to finish
  onSuccess: () => {
    return queryClient.invalidateQueries(['posts', id, 'comments'])
  }
}
{
  // 🚀 fire and forget - will not wait
  onSuccess: () => {
    queryClient.invalidateQueries(['posts', id, 'comments'])
  }
}

Mutate or MutateAsync

• mutate 는 아무것도 반환하지 않습니다.
• mutateAsync 는 돌연변이의 결과를 포함하는 Promise를 반환합니다.

mutation reponse 에 대한 접근이 필요할 때 mutateAsync 를 사용 할 수 있습니다.

항상 mutate 을 해야한다고 생각합니다! 왜?

• mutate 는 콜백을 통해 데이터나 오류에 액세스할 수 있으며 오류 처리 걱정이 없음 ➡ react query는 내부적으로 오류를 캐치하거나 무시하기에 mutate 를 사용할 때 오류 처리가 필요 없습니다. 🤟
• mutateAsync 는 Promise를 제어할 수 있기 때문에 오류를 직접 처리해야함

그럼 MutateAsync 언제 쓰나요?

• Promise가 꼭 필요할 경우
• 여러 mutations를 동시에 시작하며, 모든 mutations 이 끝나기를 기다리는 작업
• 콜백 지옥에 빠질 수 있는 의존적 mutations 이 있는 경우 필요함

Mutations only take argument for variables

반환하는 마지막 인수가 옵션 객체이므로 useMutation 은 현재 변수에 대해 하나의 인수만 사! 용할 수 있습니다. ➡ 제한적이지만, 객체를 사용하여 쉽게 해결

// 🚨 this is invalid syntax and will NOT work
const mutation = useMutation((title, body) => updateTodo(title, body))
mutation.mutate('hello', 'world')

// ✅ use an object for multiple variables
const mutation = useMutation(({ title, body }) => updateTodo(title, body))
mutation.mutate({ title: 'hello', body: 'world' })

Some callbacks might not fire

useMutation 에 대한 콜백뿐만 아닌 mutate 에 대한 콜백을 가질 수 있습니다. ➡ mutate 의 콜백 전에 useMutation 이 호출되는 것을 알아야 합니다.

🚨 변환이 완료되기 전에 컴포넌트가 마운트 해제 된 경우 mutate 콜백이 전혀 실행되지 않을 수 있습니다. ➡ 콜백에서 문제를 분리하는 것이 좋다고 생각합니다.

** useMutation 콜백 수행 ** 절대적으로 필요한 작업 및 로직 관련 작업(쿼리 무효화) ➡ 무효화 논리는 항상 동일하기 때문에 Custom hook의 재사용성이 높습니다.

** 리디렉션, 토스트 알림을 콜백으로 표시하는 것과 같은 UI관련 작업을 수행 ** ➡ 사용자가 변환이 완료되기 전에 현재 화면에서 멀리 탐색한 경우, 의도적으로 작동하지 않음

const useUpdateTodo = () =>
  useMutation(updateTodo, {
    // ✅ always invalidate the todo list
    onSuccess: () => {
      queryClient.invalidateQueries(['todos', 'list'])
    },
  })

// in the component

const updateTodo = useUpdateTodo()
updateTodo.mutate(
  { title: 'newTitle' },
  // ✅ only redirect if we're still on the detail page
  // when the mutation finishes
  { onSuccess: () => history.push('/todos') }
)

참조 링크

• TkDodo's blog - Mastering Mutations in React Query

react query를 사용하여 사용자 경험을 개선하는 방법에 대해서 알아보자. ➡ 대부분은 사람(유저)들은 Loading Spinner 를 싫어 합니다. 🤬

react query는 서로 다르지만 유사한 방법으로 Placeholder Query Data 와 Initial Query Data 의 두 가지 방법을 제공합니다.

Similarities

데이터를 캐시에 동기적으로 미리 채울 수 있는 방법을 제공합니다. ➡ 쿼리가 로딩 상태가 아닌 바로 성공 상태로 전환됩니다.

function Component() {
  // ✅ status will be success even if we have not yet fetched data
  const { data, status } = useQuery(['number'], fetchNumber, {
    placeholderData: 23,
  })

  // ✅ same goes for initialData
  const { data, status } = useQuery(['number'], fetchNumber, {
    initialData: () => 42,
  })
}

캐시에 데이터가 이미 있는 경우 둘 다 영향을 미치지 않습니다.

On cache level

각 쿼리 키에는 캐시 항목이 하나만 있습니다. ➡ react query가 애플리케이션에서 동일한 데이터를 전역적으로 공유할 수 있기 때문입니다.

staleTime 과 cacheTime 에 영향을 미치며 옵션에 따라 GC 될 수 있는 시기를 설정 할 수 있습니다.

On observer level

react query의 observer 는 하나의 캐시 엔트리를 위해 생성된 subscription 입니다. ➡ observer 는 캐시 항목이 변경되었는지 확인하고 변경 사항이 있는 경우 알림을 받습니다.

React Query Devtools 에서 쿼리 키 왼쪽의 숫자는 (1) 쿼리에 포함된 observer 수를 확인 할 수 있습니다.

• observer 는 useQuery를 호출하면 생성됩니다. ➡ 호출 할 때마다 observer 을 만들고 데이터가 변경되면 컴포넌트가 다시 렌더링됩니다. 💡 동일한 캐시 항목을 보는 여러 observer 가 있을 수 있다.

Differences

• InitialData : 캐시 수준에서 동작
• placeholderData : observer level 에서 동작

Persistence (영속성)

initialData

initialData 는 캐시에 유지됩니다.

캐시 수준에서 작동하기 때문에 하나의 initialData 만 있을 수 있으며, 캐시 항목이 생성되는 즉시(첫 번재 관찰자가 마운트될 때) 캐시에 저장됩니다.

🚨 다른 initialData로 두 번째 observer 를 마운트하려고 하면 _아무 작업도 수행하지 않습니다. _

PlaceholderData

PlaceholderData 는 캐시에 유지되지 않습니다.

해당 데이터는 서버 데이터와 관련 없는 보여주기용 가짜 데이터 입니다. react query는 실제 데이터를 가져오는 동안 해당 데이터를 보여줍니다.

observer 수준에서 작동하기 때문에 이론적으로 다른 컴포넌트에 대해 다른 placehoderData 를 가질 수 있습니다.

Background refetches

initialData

initialData 는 캐시에 유효한 데이터로 간주되므로 실제로 저장되어 오랜 시간 남아 있습니다. 만약 staleTime 이 0(기본값) 이라면 background-refetch 를 확인할 수 있습니다.

쿼리에 staleTime(ex 30초) 를 설정한 경우 초기 데이터를 동기적으로 얻을 수 있으며, 해당 데이터는 30초간 유효하기 때문에 backend에 요청할 필요가 없습니다.

✅ initialDataUpdatedAt 을 사용하여 해결 할 수 있습니다. ➡ initailData 가 생성되었을 때 react query에 알리며 고려하여 백그라운드 다시 가져오기가 트리거 됩니다.

기존 캐시 항목에서 dataUpdatedAt 타임스탬프와 initialData 를 사용할 때 매우 유용합니다.

const useTodo = (id) => {
  const queryClient = useQueryClient()

  return useQuery(['todo', id], () => fetchTodo(id), {
    staleTime: 30 * 1000,
    initialData: () =>
      queryClient
        .getQueryData(['todo', 'list'])
        ?.find((todo) => todo.id === id),
    initialDataUpdatedAt: () =>
    // ✅ initial data를 채우는데 사용한 쿼리 데이터가 
    // staleTime(30초) 더 오래된 경우 백그라운드에서 다시 가져옵니다.
      queryClient.getQueryState(['todo', 'list'])?.dataUpdatedAt,
  })
}

PlaceholderData

PlaceholderData 를 사용하면 처음으로 관찰자를 탑재할 때 항상 백그라운드에서 다시 가져옵니다. ➡ 데이터가 실제 데이터가 아니므로 react query가 실제 데이터를 가져옵니다.

데이터를 가저오는 동안 react query에서 반환된 isPlaceholderData 플래그를 얻을 수 있습니다. ✅ 이 플레그를 사용하여 사용자가 보고 있는 데이터가 실제로는 PlaceholderData 임을 시각적으로 알 수 있습니다. ➡ 실제 데이터가 들어오는 즉시 false 로 전환됩니다.

Error transitions

initailData 또는 PlaceholderData 사용 시, 백그라운드 리페치가 트리거된 다음, 쿼리가 실패한다는 가정을 새워봅니다. 어떤 상황이 발생할까요?

initialData

initailData 는 캐시에 유지되므로 refetch 오류는 다른 백그라운드 오류와 같이 처리됩니다. ➡ 쿼리는 오류 상태이지만 데이터는 여전히 존재함

PlaceholderData

쿼리는 error 상태가 되며 데이터는 undefined 가 됩니다.

언제 무엇을 사용해야 할까?

• 다른 쿼리로 부터 쿼리를 미리 채울 때 initialData
• 그 외 placeholderData

참조 링크

• TkDodo's blog - placeholder-and-initial-data-in-react-query

query key 특징

• 쿼리 키는 고유해야 합니다.
• react query가 캐시에서 키에 대한 항목을 찾으면 사용합니다.
• useQuery 와 useInfiniteQuery에는 동일한 키를 사용할 수 없습니다.

useQuery(['todos'], fetchTodos)

// 🚨 this won't work
useInfiniteQuery(['todos'], fetchInfiniteTodos)

// ✅ choose something else instead
useInfiniteQuery(['infiniteTodos'], fetchInfiniteTodos)

Automatic Refetching

쿼리는 선언형입니다.

function Component() {
  const { data, refetch } = useQuery(['todos'], fetchTodos)

  // ❓ how do I pass parameters to refetch ❓
  return <Filters onApply={() => refetch(???)} />
}

쿼리, refetching 을 명령형으로 생각하지만, "클릭"하는 데도 시간이 걸릴 수 있습니다.

refetch 의 뜻은 동일한 매개 변수를 사용하여 refetching 을 하는 것입니다.

function Component() {
  const [filters, setFilters] = React.useState()
  const { data } = useQuery(['todos', filters], () => fetchTodos(filters))

  // ✅ set local state and let it "drive" the query
  return <Filters onApply={setFilters} />
}

Always use Array Keys

참고 : React Query queryKey 관리하기

정확한 키를 알면 하나의 특정 목록을 대상으로 지정할 수 있습니다. 필요한 경우 모든 목록을 대상으로 지정할 수 있으므로 Updates from Mutation Responses 는 훨씬 더 유연해집니다.

function useUpdateTitle() {
  return useMutation(updateTitle, {
    onSuccess: (newTodo) => {
      // ✅ update the todo detail
      queryClient.setQueryData(['todos', 'detail', newTodo.id], newTodo)

      // ✅ update all the lists that contain this todo
      queryClient.setQueriesData(['todos', 'list'], (previous) =>
        previous.map((todo) => (todo.id === newTodo.id ? newtodo : todo))
      )
    },
  })
}

만약 list와 detail 구조가 많이 다르다면 이 기능이 작동하지 않을 수 있기 때문에 모든 list를 무효화 할 수 있습니다.

function useUpdateTitle() {
  return useMutation(updateTitle, {
    onSuccess: (newTodo) => {
      queryClient.setQueryData(['todos', 'detail', newTodo.id], newTodo)

      // ✅ just invalidate all the lists
      queryClient.invalidateQueries(['todos', 'list'])
    },
  })
}

URL에서 필터를 읽어 어떤 목록에 있는 데이터를 알고 있으므로 정확한 queryKey 를 구성할 수 있다면, 이 두가지 방법을 결합하여 list 에서 setQueryData 를 호출하고 다른 모든 것을 무효화 할 수 있습니다.

function useUpdateTitle() {
  // imagine a custom hook that returns the current filters,
  // stored in the url
  const { filters } = useFilterParams()

  return useMutation(updateTitle, {
    onSuccess: (newTodo) => {
      queryClient.setQueryData(['todos', 'detail', newTodo.id], newTodo)

      // ✅ update the list we are currently on instantly
      queryClient.setQueryData(['todos', 'list', { filters }], (previous) =>
        previous.map((todo) => (todo.id === newTodo.id ? newtodo : todo))
      )

      // 🥳 invalidate all the lists, but don't refetch the active one
      queryClient.invalidateQueries({
        queryKey: ['todos', 'list'],
        refetchActive: false,
      })
    },
  })
}

참조링크

• TkDodo's blog - effective-react-query-keys

인라인 함수는 Custom Hook에서 사용할 수 있는 다른 변수를 닫을 수 있기에 queryFn에 전달하는 가장 쉬운 방법입니다.

type State = 'all' | 'open' | 'done'
type Todo = {
  id: number
  state: TodoState
}
type Todos = ReadonlyArray<Todo>

const fetchTodos = async (state: State): Promise<Todos> => {
  const response = await axios.get(`todos/${state}`)
  return response.data
}

export const useTodos = () => {
  // imagine this grabs the current user selection
  // from somewhere, e.g. the url
  const { state } = useTodoParams()

  // ✅ The queryFn is an inline function that
  // closures over the passed state
  return useQuery(['todos', state], () => fetchTodos(state))
}

🚨 매개변수가 많은 경우 상당한 문제를 발생할 수 있습니다.

type Sorting = 'dateCreated' | 'name'
const fetchTodos = async (
  state: State,
  sorting: Sorting
): Promise<Todos> => {
  const response = await axios.get(`todos/${state}?sorting=${sorting}`)
  return response.data
}

쿼리에 정렬을 추가하려고합니다. ➡ fetchTodos에서 Custom Hook에서 오류가 발생할 수 있습니다. 쿼리 키가 실제 종속성과 다를 수 있는 복잡한 문제가 발생할 수 있습니다.😡

export const useTodos = () => {
  const { state, sorting } = useTodoParams()

  // 🚨 can you spot the mistake ⬇️
  return useQuery(['todos', state], () => fetchTodos(state, sorting))
}

해결방법? 모든 종속성을 포함하여 쿼리 키를 생성하여 이 문제를 해결하는 babel-plugin-react-query-key-gen 있습니다.

💡 react query에는 종속성을 처리하는 다른 기본 메서드가 포함되어 있습니다. QueryFunctionContext 사용하는 것입니다.

QueryFunctionContext

QueryFunctionContext 는 queryFn 에 인수로 전달되는 객체입니다.

const fetchTodos = async ({ queryKey }) => {
  // 🚀 we can get all params from the queryKey
  const [, state, sorting] = queryKey
  const response = await axios.get(`todos/${state}?sorting=${sorting}`)
  return response.data
}

export const useTodos = () => {
  const { state, sorting } = useTodoParams()

  // ✅ no need to pass parameters manually
  return useQuery(['todos', state, sorting], fetchTodos)
}

How to type the QueryFunctionContext

전체 타입의 안정성을 확보하고 useQuery에 전달된 queryKey에서 QueryFunctionContext 의 타입을 추론하는 것입니다.

export const useTodos = () => {
  const { state, sorting } = useTodoParams()

  return useQuery(
    ['todos', state, sorting] as const,
    async ({ queryKey }) => {
      const response = await axios.get(
        // ✅ this is safe because the queryKey is a tuple
        `todos/${queryKey[1]}?sorting=${queryKey[2]}`
      )
      return response.data
    }
  )
}

🚨 여전히 많은 단점이 있습니다.

• 무언가를 사용하기 위해 클로저 내부에 쿼리를 생성해야 합니다.
• queryKey 를 사용하여 위의 방법으로 URL을 작성하는 것은 모든 문자열을 지정할 수 있으므로 여전히 안전하지 않습니다.

Query Key Factories

키를 빌드하기 위한 typesafe query key factory 가 있는 경우 반환 타입을 사용하여 QueryFunctionContext 를 입력할 수 있도록 합니다.

참고 : react-query-querykey

// index.ts
import {
  mergeQueryKeys,
  inferQueryKeyStore,
} from "@lukemorales/query-key-factory";

export const postQueryKeys = createQueryKeys("posts", {
  getPosts: (page?: number, limit?: number) => ({
    queryKey: [{ page, limit }],
  }),
});

// postTypes.ts
export const queries = mergeQueryKeys(postQueryKeys);
export type QueryKeys = inferQueryKeyStore<typeof queries>;
export type GetPostListQuery = QueryKeys["posts"]["getPosts"];

export interface Post {
  userId: number;
  id: number;
  title: string;
  body: string;
}

// queries.ts
const getPostsApi = async (
  ctx: QueryFunctionContext<GetPostListQuery["queryKey"]>,
): Promise<Post[]> => {
  const [, , { page, limit }] = ctx.queryKey;
  const response = await axiosClient.get<Post[]>(
    "https://jsonplaceholder.typicode.com/posts",
    {
      params: { _page: page, _limit: limit },
    },
  );
  return response.data;
};

const useGetPosts = (page: number, limit: number) => {
  return useQuery(
    queries.posts.getPosts(page, limit).queryKey,
    getPostsApi,
  );
};

QueryFunctionContext 타입은 react query에 의해 export 됩니다. queryKey의 타입을 정의하는 하나의 제네릭을 사용합니다. 해당 구조에 맞지 않는 키를 사용하면 타입 오류가 발생하게 됩니다.

참조

• tkdodo blog - query-function-context

이전 섹션에서 React Query의 데이터 변환 에서 데이터의 길이가 변경될 경우에만 다시 렌더링된다고 정의했지만, 기술적으로 사실이 아니다. 🤦

background-fetch 를 다시 실행할 때마다 구성 요소는 다음 쿼리 정보를 두번 re-render 처리합니다.

{ status: 'success', data: 2, isFetching: true, isLoading: true, ... }
{ status: 'success', data: 2, isFetching: false, isLoading: false, ... }

isFetching과 isLoading 무슨 차이?

정의

isFetching

isFetching 은 어떠한 react query 요청 내부의 비동기 함수 처리여부에 따라 true/false 상태로 처리됩니다. ➡ 캐시 유무와 상관없이 데이터를 가져오는 유무만 확인하여 true/false 상태로 처리합니다.

isLoading

isLoading 은 캐시 데이터조차 없이, 처음 실행된 쿼리일 때 loading 에 따라 true/false 상태로 처리됩니다. ➡ 어떤 데이터를 호출하여 웹 브라우저 상에 캐시가 존재한 상태에서 같은 쿼리 키의 데이터 를 중복으로 호출한다면 isLoading 은 무조건 false 상태입니다.

isFetching 와 isLoading은 비슷하게 loading 개념을 사용하지만 기존 캐시 데이터 여부에 따라 다르게 동작합니다.

언제 구분해서 사용할까?

• isFetching : 서버에 데이터 요청을 다시 할 경우 (캐시 데이터가 존재할 때)
• isLoading : 서버에 데이터 요청을 처음 할 경우

notifyOnChangeProps

react query는 notifyOnChangeProps 옵션이 있습니다. props 중 하나가 변경된 경우에만 해당 observer 에게 변경 사항을 알려주도록 observer 수준에서 설정할 수 있습니다.

export const useTodosQuery = (select, notifyOnChangeProps) =>
  useQuery(['todos'], fetchTodos, { select, notifyOnChangeProps })
export const useTodosCount = () =>
  useTodosQuery((data) => data.length, ['data'])

이렇게 적용하면 useQuery의 response 값의 data 만 변경 된 경우 리렌더링이 됩니다.

Staying in Sync

export const useTodosCount = () =>
  useTodosQuery((data) => data.length, ['data'])

function TodosCount() {
  // 🚨 we are using error, but we are not getting notified if error changes!
  const { error, data } = useTodosCount()

  return (
    <div>
      {error ? error : null}
      {data ? data : null}
    </div>
  )
}

🚨 status를 이용하여 조건부 렌더링을 하는 경우 문제가 발생함 ➡ status 의 변경여부를 감지할 수 없음

• 플래그 값을 사용하는 것이 아닌, notifyOnChangeProps 목록을 컴포넌트에서 실제로 사용하고 있는 필드와 동기화하면 됩니다.

🚨 Custom Hook에서 하드코딩한 경우 실제로 무엇을 사용할지 모르기 때문에 문제가 발생 ➡ 동기화 작업을 하지 않고 데이터 속성만 관찰하는 경우 오류가 표시되면, 컴포넌트가 다시 렌더링되지 않으므로 오래된 값 입니다.

Tracked Queries

💡 notifyOnChangeProps 를 tracked 로 설정하면 react query는 렌더링 중에 사용중인 필드를 추적하며, 이 필드를 사용하여 목록을 계산합니다. ➡ 목록을 수동으로 지정하는 것과 정확히 동일한 방식으로 최적화되며, 사용자가 고려할 필요가 없습니다.

• 해당 옵션은 모든 쿼리에 전역적으로 설정할 수 있습니다.

v4 부터는 기본적으로 notifyOnChangeProps: 'tracked' 옵션이 설정되어 있습니다. ➡ notifyOnChangeProps: 'all' 설정하여 옵트아웃 할 수 있습니다.

const queryClient = new QueryClient({
   defaultOptions: {
     queries: {
         notifyOnChangeProps: 'tracked',
     },
   },
})

고려사항

구조분해(destructuring)를 쓰지마세요

일반적인 분해 할당은 괜찮지만, 그 외는 하지마세요.

// 🚨 will track all fields
const { isLoading, ...queryInfo } = useQuery(...)

// ✅ this is totally fine
const { isLoading, data } = useQuery(...)

추적된 쿼리는 render 중에만 작동합니다.

작동 중인 필드에만 엑세스하면 추적되지 않습니다. 🚨 종속성 배열로 인해 매우 어려운 경우

const queryInfo = useQuery(...)

// 🚨 will not corectly track data
React.useEffect(() => {
    console.log(queryInfo.data)
})

// ✅ fine because the dependency array is accessed during render
React.useEffect(() => {
    console.log(queryInfo.data)
}, [queryInfo.data])

필드를 한번 추적하면 컴포넌트 생명동안 추적합니다.

추적된 쿼리는 각 render에서 재설정되지 않으므로 필드를 한 번 추적하면 관찰자(Observer)의 수명동안 추적됩니다.

const queryInfo = useQuery(...)

if (someCondition()) {
// 🟡 we will track the data field if someCondition was true in any previous render cycle
    return <div>{queryInfo.data}</div>
}

Structural sharing

이 기능을 사용한다면 모든 수준에서 데이터 참조 ID를 유지할 수 있습니다.

[
  { "id": 1, "name": "Learn React", "status": "active" },
  { "id": 2, "name": "Learn React Query", "status": "todo" }
]

다음과 같은 데이터 구조에서 첫 번째 todo를 'done' 상태로 전환하고 re-fetch를 한다면, backend에서 새로운 jsonData 값을 얻을 수 있습니다.

[
-  { "id": 1, "name": "Learn React", "status": "active" },
+  { "id": 1, "name": "Learn React", "status": "done" },
  { "id": 2, "name": "Learn React Query", "status": "todo" }
]

react query는 이전 상태와 새 상태를 비교하며, 가능한 많은 이전 상태를 유지합니다. todo를 업데이트했기 때문에 todos 배열 데이터가 새로워집니다. ➡ id:2 에 대한 개체는 이전 상태의 개체와 동일한 참조가 됩니다.

참조

• https://tkdodo.eu/blog/react-query-render-optimizations