Typescript's puzzling selection of the incorrect overload

Question

Typescript's puzzling selection of the incorrect overload

I have a method structured as shown below:

class Bar {
    public executeInWorker(cb: () => void): void;
    public executeInWorker(cb: () => Promise<void>): void | Promise<void>;
    public executeInWorker(cb: () => void | Promise<void>): void | Promise<void> {
        if (cluster.isPrimary ?? cluster.isMaster) {
            return;
        }

        return cb();
    }
}

My goal is to be able to pass in either a synchronous or asynchronous function and have the overloaded method return the correct type (i.e. void for a sync function and Promise<void> for an async function).

This implementation works correctly with a sync callback:

// result will be of type void
const result = new Bar().executeInWorker(() => {})

However, it encounters issues when used with an async callback:

// result is expected to be of type Promise<void>, but becomes void
const result = new Bar().executeInWorker(async () => {})

How can I resolve this problem?

typescript

Answer 1

Answer №1

There seems to be a peculiar behavior where a function that returns a promise of void can be converted to a function that returns void (possibly because the return value of a function returning void should never be utilized, allowing a function A that returns a non-void type with a compatible parameter signature to be considered compatible with function B even if B returns void). However, the reverse is not true:

const okay: () => void = async () => {};
const notOkay: () => Promise<void> = () => {};

The section on function overloads in the TypeScript handbook explains:

To determine the correct type check, the compiler follows a process similar to underlying JavaScript. It examines the overload list and, starting with the first overload, tries calling the function with the provided parameters. If it finds a match, this overload is selected as the correct one. Therefore, it's recommended to order overloads from most specific to least specific.

As noted earlier, your overload that accepts a synchronous callback and returns void can handle either a sync or async callback. The overload that accepts an async callback can only take an async callback, not a sync one, making it the "more specific" choice.

To resolve the issue, I believe you just need to rearrange your overloads like this:

class Foo {
    public runInWorker(cb: () => Promise<void>): void | Promise<void>;
    public runInWorker(cb: () => void): void;
    public runInWorker(cb: () => void | Promise<void>): void | Promise<void> {
        return cb();
        // ...

Answer 2

There seems to be a peculiar behavior where a function that returns a promise of void can be converted to a function that returns void (possibly because the return value of a function returning void should never be utilized, allowing a function A that returns a non-void type with a compatible parameter signature to be considered compatible with function B even if B returns void). However, the reverse is not true:

const okay: () => void = async () => {};
const notOkay: () => Promise<void> = () => {};

The section on function overloads in the TypeScript handbook explains:

To determine the correct type check, the compiler follows a process similar to underlying JavaScript. It examines the overload list and, starting with the first overload, tries calling the function with the provided parameters. If it finds a match, this overload is selected as the correct one. Therefore, it's recommended to order overloads from most specific to least specific.

As noted earlier, your overload that accepts a synchronous callback and returns void can handle either a sync or async callback. The overload that accepts an async callback can only take an async callback, not a sync one, making it the "more specific" choice.

To resolve the issue, I believe you just need to rearrange your overloads like this:

class Foo {
    public runInWorker(cb: () => Promise<void>): void | Promise<void>;
    public runInWorker(cb: () => void): void;
    public runInWorker(cb: () => void | Promise<void>): void | Promise<void> {
        return cb();
        // ...

Answer 3

Answer №2

Consider using generics over other options

class Bar {
  public executeInWorker<T>(func: () => T): T {
    return func();
  }
}

Answer 4

Consider using generics over other options

class Bar {
  public executeInWorker<T>(func: () => T): T {
    return func();
  }
}

Answer 5

Answer №3

Let's address the issue starting with this line:

    public runInWorker(cb: () => Promise<void>): void | Promise<void>;

If a function returns a promise, then the return value should also be a promise. Therefore, it should be modified to:

    public runInWorker(cb: () => Promise<void>): Promise<void>;

However, there appears to be inconsistencies in mixing promises and callbacks in your code that may indicate a code smell.

It is recommended to stick with either callbacks or promises exclusively, not a combination of both. Your functions should either accept a callback as input and return nothing, or take no callback and return a promise. Mixing callbacks that return promises can lead to confusion.

To resolve this, you could approach it like this:

public run(cb: (err: Error, data: Data) => void): void;
public run(): Promise<Data>;
public run(cb?: (err: Error, data: Data) => void): void | Promise<Data> {
  // This version of the function is primarily designed to work with callbacks,
  // so we wrap it in a promise here for consistency.
  if (!cb) {
    return new Promise((resolve, reject) => {
        this.run((err, data) => err ? reject(err) : resolve(data))
    })
  }

  // Include the remaining functionality that works with a callback here
}

Answer 6

Let's address the issue starting with this line:

    public runInWorker(cb: () => Promise<void>): void | Promise<void>;

If a function returns a promise, then the return value should also be a promise. Therefore, it should be modified to:

    public runInWorker(cb: () => Promise<void>): Promise<void>;

However, there appears to be inconsistencies in mixing promises and callbacks in your code that may indicate a code smell.

It is recommended to stick with either callbacks or promises exclusively, not a combination of both. Your functions should either accept a callback as input and return nothing, or take no callback and return a promise. Mixing callbacks that return promises can lead to confusion.

To resolve this, you could approach it like this:

public run(cb: (err: Error, data: Data) => void): void;
public run(): Promise<Data>;
public run(cb?: (err: Error, data: Data) => void): void | Promise<Data> {
  // This version of the function is primarily designed to work with callbacks,
  // so we wrap it in a promise here for consistency.
  if (!cb) {
    return new Promise((resolve, reject) => {
        this.run((err, data) => err ? reject(err) : resolve(data))
    })
  }

  // Include the remaining functionality that works with a callback here
}

Typescript's puzzling selection of the incorrect overload

Answer №1

Answer №2

Answer №3

Similar questions

What is the way to send custom properties to TypeScript in combination with StyledComponents?

In Angular, is there a way to transform time into the format of YYYY-MM-DDThh:mm:ssTZD?

Is there a more efficient approach to displaying a list of elements and sharing state in React with TypeScript?

Break apart the string and transform each element in the array into a number or string using a more specific type inference

I have encountered limitations with useFormik where it does not accept null values for initialValues, even while utilizing a validationSchema

"Efficient ways to calculate the total sum of an array of objects based on a specific property

failure of pipe during search for art gallery information

What is the best way to filter or choose tuples based on their inclusion in a certain group

Angular 2 module that is loaded lazily - service does not follow singleton pattern

Angular 8 combined with Mmenu light JS

Utilize an external JavaScript function within a React and TypeScript document

TypeScript implementation of internationalization message extraction in Create React App

Encountering unusual results while utilizing interfaces with overloaded arguments

Learn the steps to assign a Base64 URL to an image source

Tips for running a dry default with Angular CLI

What is the correct way to add type annotations to an Axios request?

Mapping Interface Types in Typescript

Dealing with numerous dynamically generated tables while incorporating sorting in Angular: a comprehensive guide

Apollo GraphQL has initiated the detection of a new subscription

The function getStaticPaths() will generate a 404 error, indicating that the page