TypeScript Deep-Dive: 부분 타입 추론

TypeScript의 꽃🌷이라 할 수 있는 타입추론(Type Inference)과 Generic Type의 부분 타입추론 문제 대해 알아봅니다.

들어가기 앞서..

여러분은 모나드라는 개념을 알고 있나요?

어떤 개념을 비로소 깨닫는 순간을 ‘Aha moment’라 부르기도 하는데, 더글라스 크록포드의 말을 인용하자면, 모나드를 이해하는 Aha moment를 겪는 순간, 다른 사람에게 모나드를 설명할 수 없게 되는 저주에 걸린다고 한다.
그런데, 모나드만 그러한가? 세상의 많은 이해와 문제들이 비슷한 상황에 놓여 있다. 간략화한 적당한 비유를 통해 설명하는 게 처음 접하는 사람들에게 쉽게 느껴지겠지만, 대부분의 경우는 결국 불필요한 오해를 가져온다.

출처 원문

 

만약 이 글을 읽고 부분 타입 추론 문제와 이를 해결하기 위한 방안이 잘 이해되지 않는다면 저는 모나드의 저주에 걸린 것입니다...

이 주제에 대해 관심이 생긴다면 꼭 끝까지 파헤쳐 개념을 이해하시길 바랍니다.

이 글은 타입스크립트를 활용해 보았으며, Generic Type에 대한 기본적인 이해가 있음을 바탕으로 합니다.

---

예시로 등장하는 custom swr hook의 부분타입 추론 문제는 swr@2.1.0에서 발생하였고, swr@2.1.1에서 이 문제가 해결되었습니다.

custom swr hook의 BlockingData타입까지 매끄러운 타입추론을 가능하게 하고자 한다면, 부분타입 추론의 문제와 해결방안까지 확인해보시길 추천드립니다.

 

TL;DR

TypeScript Generic은 완벽하지 않습니다. 조금 더 자세히 말해보자면 Generic의 부분적인 추론은 완벽하지 않습니다.

TypeScript는 모든 Generic에 대해서 추론해 낼 수 있지만, 부분적인 추론에 대해서는 지원하지 않습니다. (적어도 현재까지는)

부분 추론 타입이 제한되는 상황에서 Generic Function에 대해 정상적인 추론을 위해 몇 가지 방안이 존재합니다.

TypeScript Playground

---

현재 회사에서는 서버 상태관리도구로 swr을 채택하여 활용중이고, 재사용을 고려한 custom swr hook을 만들어 활용 중에 있습니다.

대략적인 모습은 아래와 같습니다.

export type UseRequestOption<Data> = SWRConfiguration<Data>;

export function useRequest<Data>(endpoint: string, options?: UseRequestOption<Data>) {
  return useSWR(
    endpoint,
    async url => {
      const resp = await axiosInstance.get<Data>(url);
      return resp.data;
    },
    options,
  );
}

이를 활용해, 재사용 가능하도록 커스텀 훅을 만들어 활용하게 됩니다.

interface Post {
  title: string;
}

interface UsePostsReturn {
  posts: Post[];
}

export function usePosts(option?: UseRequestOption<UsePostsReturn>) {
  return useRequest<UsePostsReturn>('/api/posts', option);
}

실제 사용할 때에는 이런 모습이 됩니다. 사용처에서 swr option을 활용하여 각각의 처리가 가능하도록 합니다.

이 상황에서 부분 타입추론의 문제가 발생합니다.

const Component = () => {
  const { data } = usePosts();
  // ^? data: UsePostsReturn
};

swr의 반환값 중 data는 undefined가 될 수 있는 상황이 존재합니다. 즉 캐시된 데이터가 없는 상황입니다.

swr은 suspense나 fallbackData 옵션을 주어 BlockingData(NotNullable) 타입으로 만들 수 있지만, 주지 않았음에도 BlockingData로 처리되었습니다. 원인을 살펴봅시다.

 

TypeScript Generic은 완벽하지 않습니다. 조금 더 자세히 말해보자면 Generic의 부분적인 추론은 완벽하지 않습니다.

TypeScript는 모든 Generic에 대해서 추론해 낼 수 있지만, 부분적인 추론에 대해서는 지원하지 않습니다. (적어도 현재까지는)

type Foo = <A = any, B = any, C = any>(a: A, b: B, c: C) => [A, B, C]
const foo: Foo = (a, b, c) => [a, b, c]
const bar1 = foo(1, 2, 3)
//     ^? const bar1: [number, number, number]
const bar2 = foo<number>(1, 2, 3)
//     ^? const bar2: [number, any, any]  - Passing just one explicit generic to `foo` removes type inference

⭐️ Generic 인수를 부분적으로 전달할 때, 나머지는 기본값을 따라갈 뿐입니다. 이것이 부분 타입추론의 문제입니다.

그럼, swr에서 발생한 문제를 짚어보기 위해 swr을 단순화한 버전의 SWRHook을 만들어봅니다.

type MySWRConfig<Data> = { fallbackData?: Data };

type BlockingData<Data = any, Options = MySWRConfig<Data>> = Options extends undefined
  ? false
  : Options extends { fallbackData: Data; }
  ? true
  : false;

type MySWRResponse<Data, Options = MySWRConfig<Data>> = {
  data: BlockingData<Data, Options> extends true ? Data : Data | undefined;
};

interface MyHook {
  <Data>(key: string): MySWRResponse<Data>;
  <Data, Config extends MySWRConfig<Data> | undefined = MySWRConfig<Data>>(key: string, config: Config | undefined): MySWRResponse<Data, Required<Config>>;
}

const mySWR: MyHook = () => {}

mySWR을 통해 확인해봅시다.

type User = {
  name: string;
  age: number
};

const fallbackData: User = { name: 'Jonghwan', age: 17 };

const t0 = mySWR<User>('/');
const t1 = mySWR<User>('/', {});
const t2 = mySWR<User>('/', { fallbackData });

⭐️ Quiz. mySWR로 작성된 t0, t1, t2 중 BlockingData가 아닌 것(data=undefined가 될 수 있는)은 무엇이고 왜 그럴까요?

앞서서 부분 타입추론은 완벽하지 않다고 했습니다. 세 가지 경우, 모두 다 Generic 유형을 완벽히 지정해주지 않았습니다.

그렇다면 부분추론 제한에 의해, Config는 기본값인 MySWRConfig<Data>가 맵핑됩니다.(이때 실제 함수(mySWR)를 호출할 때 전달한 config의 모양이 어떻든 상관없습니다.)

실제 전달된 option의 모양과는 무관하게, Generic 유형은 있다고 판단되니 반환 타입은 Requred<Config>…, 이 타입은 { fallbackData: Data } 유형이 되고.. BlockingData 검사에는 통과하고, Data가 됩니다.

이것이 우리의 custom SWR hook이 NonNullable한 이유였습니다.

TypeScript AST Viewer

그럼, 부분 타입 추론의 문제를 어떻게 해결할 수 있습니까?

부분타입추론을 이해하고, Generic 유형들을 수정해 볼 수 있습니다. 그리고, TypeScript가 온전히 타입추론할 수 있도록 만들어줍니다.

interface MyHook {
  <Data = any>(key: string): MySWRResponse<Data>;
  // 부분타입추론으로 항상 존재하는 기본값에서 undefined가 될 수 있음으로 변경합니다
- <Data = any, Config extends MySWRConfig<Data> | undefined = MySWRConfig<Data>>(key: string, config: Config | undefined): MySWRResponse<Data, Required<Config>>;
+ <Data = any, Config extends MySWRConfig<Data> | undefined = MySWRConfig<Data> | undefined>(key: string, config: Config): MySWRResponse<Data, Config>;
}

Generic 인수를 모두 추론 가능하게 만들어주거나, 모두 명시적으로 지정합니다.

const config = { fallbackData };

const t0 = mySWR<User>('/');
t0.data.name; // data = undefined

const t1 = mySWR<User>('/', {});
t1.data.name; // data = undefined

const t2 = mySWR<User, typeof config>('/', config);
t2.data.name; // data = User

// 조금 더 본래의 swr을 구현했다고 가정, (fetcher를 포함)
const t3 = mySWR('/', () => { return {} as User }, { });
t3.data // data = User | undefined
const t4 = mySWR('/', () => { return {} as User }, { fallbackData });
t4.data // data = User

만족스럽습니다. 이제야 타입 추론이 정상적으로 동작합니다.

하지만, 개발자가 모든 제네릭 유형을 할당해 주는 일은 현실세계에서는 재사용성을 고려한 추상화의 범위에 따라 어렵고 번거로운 일이 될 가능성이 많습니다.

 

더 나은 방법은 없을까요?

부분 추론 타입이 제한되는 상황에서 Generic Function에 대해 정상적인 추론을 위해 몇 가지 방안이 존재합니다.

TypeScript Playground

 

위 내용 중 커링 방식으로 createSWRHook을 만들어 Custom SWR Hook을 만들었고, 정확하게 타입추론이 될 수 있도록 개선해 볼 수 있습니다.

여기까지 부분타입추론 문제에 대해 알아보았고, 나아가 보다 완벽한 타입추론 상태를 만드는 테크닉에 대해 살펴보았습니다.