Confusing behavior of TypeScript type inference: Why do the four function return value types have the same result, and the trap of union types in conditional types?

Singular behavior of TypeScript type inference: Four functions return the same result defined by the value type and the trap of joint types in the conditional type

This article analyzes some puzzling type inference behavior in TypeScript. We will explore why four seemingly different type definitions yield the same results and explain the problems that may be encountered when using union types in conditional types.

First, let's observe these four getReturnType type definitions:

 type getReturnType1<t> = T extends (...args: never) => infer R ? R : never;
type getReturnType2<t> = T extends (...args: never[]) => infer R ? R : never;
type getReturnType3<t> = T extends (...args: any[]) => infer R ? R : never;
type getReturnType4<t> = T extends (...args: any) => infer R ? R : never;</t></t></t></t>

Although ...args are never , never[] , any[] and any , these four definitions produce the same results in practical applications. This is because in TypeScript's type system, the role of function parameter types in type inference is not what we intuitively think. never represents a value that never exists, never[] represents an empty array, any[] represents an arbitrary type array, any represents any type. However, extends condition judgment mainly focuses on the return value type of the function infer R , and the impact of the parameter type is relatively small and can even be ignored. Therefore, as long as the passed T is a function type, the return value type can be inferred and assigned to R ; if T is not a function type, it will return never .

Next, we analyze another question, involving conditional types and union types:

 type Props<t extends major rescategorylabel> = {
  labels: T[];
  setSelect: (index: number, label: T extends Major ? Major : ResCategoryLabel) => void;
  xxx;
};

const changeSelect = (
  index: number,
  label: Major | ResCategoryLabel,
  e: React.MouseEvent<htmlanchorelement> | React.TouchEvent<htmlanchorelement>
) => {
  setSelect(index, label); // Type error activeTabToCenter(e.currentTarget as HTMLElement);
};</htmlanchorelement></htmlanchorelement></t>

In this code, the Props type defines a generic T that limits it to a joint type of Major or ResCategoryLabel . The second parameter label of setSelect function is defined as T extends Major ? Major : ResCategoryLabel . The original intention is to determine the type of label based on the type of T : if T is Major , then label is Major ; otherwise it is ResCategoryLabel . However, since T is a union type, TypeScript cannot determine the specific type of T at compile time, resulting in the type check of setSelect function failing. This is because when the conditional type processes union types, each type will be judged separately, and the final result is a union of all branch results. In this case, the type of label will eventually become Major | ResCategoryLabel , which does not match the type of label in the changeSelect function, resulting in a type error. Workarounds may require redesigning the type definition, such as using type guards or finer type inference to avoid this problem.

The above is the detailed content of Confusing behavior of TypeScript type inference: Why do the four function return value types have the same result, and the trap of union types in conditional types?. For more information, please follow other related articles on the PHP Chinese website!