A versatile generic type infused with dynamic typing and optional parameter flexibility

Question

A versatile generic type infused with dynamic typing and optional parameter flexibility

Looking to develop a function that can accept an optional errorCallback parameter. In cases where the consumer of this function does not provide a callback, I aim to default to a preset handler. The key criteria here are strong typing and utilizing the return type defined by the consumer's custom errorCallback, falling back on my tailored error handler's return type when necessary.

Below you'll find the code snippet:

export enum ErrorType {
    VALIDATION_ERROR,
    API_ERROR,
    UNKNOWN_ERROR,
    UNAUTHORIZED
}

type MockZodType ={}

type MockResponseError = {}

export type ServiceError<TSchema extends MockZodType> =
    | {
            type: ErrorType.VALIDATION_ERROR;
            message: string;
            status: number;
            data: TSchema;
            originalError: MockResponseError;
      }
    | {
            type: ErrorType.API_ERROR;
            message: string;
            status: number;
            data: unknown;
            originalError: MockResponseError;
      }
    | {
            type: ErrorType.UNKNOWN_ERROR;
            message: string;
            status: number;
            data: unknown;
            originalError: unknown;
      }
    | {
            type: ErrorType.UNAUTHORIZED;
            message: string;
            status: number;
            data: unknown;
            preventDefaultHandler: boolean;
            originalError: MockResponseError;
      };

export type ServiceCallOptions<
    TServiceCallReturn extends Promise<unknown>,
    TSchema extends MockZodType = never,
    TErrorCallbackReturn extends Promise<unknown> = Promise<ServiceError<TSchema>>
> = {
    serviceCall: () => TServiceCallReturn;
    errorSchema?: TSchema;
    errorCallback?: (e: ServiceError<TSchema>) => TErrorCallbackReturn;
};

export async function callService<
    TServiceCallReturn extends Promise<unknown>,
    TSchema extends MockZodType = never,
    TErrorCallbackReturn  extends Promise<unknown> = Promise<ServiceError<TSchema>>
>({
    serviceCall,
    errorSchema,
    errorCallback = async (e)=> {
        if (e.type === ErrorType.UNAUTHORIZED && !e.preventDefaultHandler) {
            // some custom default handler;
        }
        return e; 
    }
}: ServiceCallOptions<TServiceCallReturn, TSchema, TErrorCallbackReturn>) {
    // some logic
}

An error emerges from the default value in the errorCallback parameter with the following message:

Type '(e: ServiceError<TSchema>) => Promise<ServiceError<TSchema>>' is not assignable to type '(e: ServiceError<TSchema>) => TErrorCallbackReturn'.
  Type 'Promise<ServiceError<TSchema>>' is not assignable to type 'TErrorCallbackReturn'.
    'Promise<ServiceError<TSchema>>' is assignable to the constraint of type 'TErrorCallbackReturn', but 'TErrorCallbackReturn' could be instantiated with a different subtype of constraint 'Promise<unknown>'.

No interest in using overloads, so why does it fail to work as expected?

To test or revise the code, check out the ts playground.

typescript

Answer 1

Answer №1

The issue lies in the fact that when a generic function is called, it is the caller who specifies the type arguments, not the function writer. Although the compiler can often infer the types, it does so on behalf of the caller and not the implementer. The implementer may set default type arguments for cases where inference is not possible, but the caller always has the option to manually define the type arguments based on their constraints.

Even if your intention is for the compiler to use

Promise<ServiceError<TSchema>>

as the type argument for TErrorCallbackReturn when the errorCallback property is omitted by the caller, this cannot be guaranteed. A caller could bypass this logic by explicitly specifying unexpected type arguments like so:

const f = await callService<
    Promise<string>, {}, Promise<number>
>({ serviceCall: async () => "a" });

In this scenario, the caller is asserting that the missing errorCallback property would return a number, which contradicts the expected behavior defined by the default argument. This mismatch results in a compilation error stating that 'Promise<ServiceError<TSchema>>' is assignable to 'TErrorCallbackReturn', but there exists a potential subtype conflict.

To address this issue, one approach is to utilize function overloads, providing explicit control over the available call signatures visible to the caller. By doing this, passing the third type argument without also providing the expected errorCallback property becomes impossible.

async function callService<
    TServiceCallReturn extends Promise<unknown>,
    TSchema extends MockZodType = never,
>(arg: {
    serviceCall: () => TServiceCallReturn, errorSchema?: TSchema,
    errorCallback?: never
}): Promise<void>;

async function callService<
    TServiceCallReturn extends Promise<unknown>,
    TSchema extends MockZodType = never,
    TErrorCallbackReturn extends Promise<unknown> = Promise<ServiceError<TSchema>>
>(arg: {
    serviceCall: () => TServiceCallReturn, errorSchema?: TSchema,
    errorCallback: (e: ServiceError<TSchema>) => TErrorCallbackReturn
}): Promise<void>;

If significant refactoring is not desired, another solution is to acknowledge the unlikely nature of such invalid calls and assert the correct type for the default callback argument. An example of this approach might look like:

async function callService<
    TServiceCallReturn extends Promise<unknown>,
    TSchema extends MockZodType = never,
    TErrorCallbackReturn extends Promise<unknown> = Promise<ServiceError<TSchema>>
>({
    serviceCall,
    errorSchema,
    errorCallback = (async (e: ServiceError<TSchema>) => {
        if (e.type === ErrorType.UNAUTHORIZED && !e.preventDefaultHandler) {
            // some custom default handler;
        }
        return e;
    }) as (e: ServiceError<TSchema>) => TErrorCallbackReturn
}: ServiceCallOptions<TServiceCallReturn, TSchema, TErrorCallbackReturn>) { }

This adjustment resolves the compiler error, provided the assertion remains accurate, ensuring the functionality behaves as intended.

Playground link to code

Answer 2

The issue lies in the fact that when a generic function is called, it is the caller who specifies the type arguments, not the function writer. Although the compiler can often infer the types, it does so on behalf of the caller and not the implementer. The implementer may set default type arguments for cases where inference is not possible, but the caller always has the option to manually define the type arguments based on their constraints.

Even if your intention is for the compiler to use

Promise<ServiceError<TSchema>>

as the type argument for TErrorCallbackReturn when the errorCallback property is omitted by the caller, this cannot be guaranteed. A caller could bypass this logic by explicitly specifying unexpected type arguments like so:

const f = await callService<
    Promise<string>, {}, Promise<number>
>({ serviceCall: async () => "a" });

In this scenario, the caller is asserting that the missing errorCallback property would return a number, which contradicts the expected behavior defined by the default argument. This mismatch results in a compilation error stating that 'Promise<ServiceError<TSchema>>' is assignable to 'TErrorCallbackReturn', but there exists a potential subtype conflict.

To address this issue, one approach is to utilize function overloads, providing explicit control over the available call signatures visible to the caller. By doing this, passing the third type argument without also providing the expected errorCallback property becomes impossible.

async function callService<
    TServiceCallReturn extends Promise<unknown>,
    TSchema extends MockZodType = never,
>(arg: {
    serviceCall: () => TServiceCallReturn, errorSchema?: TSchema,
    errorCallback?: never
}): Promise<void>;

async function callService<
    TServiceCallReturn extends Promise<unknown>,
    TSchema extends MockZodType = never,
    TErrorCallbackReturn extends Promise<unknown> = Promise<ServiceError<TSchema>>
>(arg: {
    serviceCall: () => TServiceCallReturn, errorSchema?: TSchema,
    errorCallback: (e: ServiceError<TSchema>) => TErrorCallbackReturn
}): Promise<void>;

If significant refactoring is not desired, another solution is to acknowledge the unlikely nature of such invalid calls and assert the correct type for the default callback argument. An example of this approach might look like:

async function callService<
    TServiceCallReturn extends Promise<unknown>,
    TSchema extends MockZodType = never,
    TErrorCallbackReturn extends Promise<unknown> = Promise<ServiceError<TSchema>>
>({
    serviceCall,
    errorSchema,
    errorCallback = (async (e: ServiceError<TSchema>) => {
        if (e.type === ErrorType.UNAUTHORIZED && !e.preventDefaultHandler) {
            // some custom default handler;
        }
        return e;
    }) as (e: ServiceError<TSchema>) => TErrorCallbackReturn
}: ServiceCallOptions<TServiceCallReturn, TSchema, TErrorCallbackReturn>) { }

This adjustment resolves the compiler error, provided the assertion remains accurate, ensuring the functionality behaves as intended.

Playground link to code

A versatile generic type infused with dynamic typing and optional parameter flexibility

Answer №1

Similar questions

Leverage the compiler API to perform type inference

having difficulty interpreting the information from angular's httpclient json request

Derive data type details from a string using template literals

Can you explain the distinction between Observable<ObservedValueOf<Type>> versus Observable<Type> in TypeScript?

Utilizing the WebSocket readyState to showcase the connection status on the application header

Disabling FormArray on-the-fly in Angular

Passing a custom data type from a parent component to a child component in React

Issue with Pagination functionality when using Material-UI component is causing unexpected behavior

Guide to customizing Material UI theme using Typescript in a separate file

Encountered issue when attempting to insert items into the list in EventInput array within FullCalendar and Angular

Is there a way for me to showcase a particular PDF file from an S3 bucket using a custom URL that corresponds to the object's name

merging JavaScript objects with complex conditions

What is the method for dynamically assigning a name to ngModel?

A script object must only permit one property at a time

Having trouble accessing the theme in a styled component with @emotion/styled

Module 'ngx-bootstrap' not found in project

Developing middleware for managing event handlers

I am looking to update my table once I have closed the modal in Angular

When working with Typescript, you can declare an interface and split its definition across multiple files

Utilizing TypeScript path aliases in a Create React App project with TypeScript and ESLint: A step-by-step guide