question-mark
Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

Improve typings by using function overloads

See original GitHub issue

The Typescript signatures are sometimes too loose and unnecessarily hard to use. Take getLocation as an example:

export default function getLocation(this: WebdriverIO.Element, prop?: 'x' | 'y'): Promise<number | {
    x: number;
    y: number;
}>;

This is hard to use because the return type is not bound to the input type. I have to do a type cast which should not be needed.

Describe the solution you’d like This could be easily solved by using overload signatures like this:

export function getLocation(this: WebdriverIO.Element): Promise<{
    x: number;
    y: number;
}>
export function getLocation(this: WebdriverIO.Element, prop: 'x' | 'y'): Promise<number>
function getLocation(this: WebdriverIO.Element, prop?: 'x' | 'y'): Promise<number | {
    x: number;
    y: number;
}> {
   // Implementation does not need to change ...
}

Additional context

This is just an example that - together with getSize - jumped me right in the face while updating our codebase to WebdriverIO 7.

Issue Analytics

  • State:closed
  • Created 3 years ago
  • Reactions:4
  • Comments:9 (8 by maintainers)

github_iconTop GitHub Comments

1reaction
azygiscommented, Mar 6, 2021

Apparently I am also working on the same issue that @iamkenos works on and created a draft-ish PR #6555. ~I don’t really see the problem that you have - there is no need to “redeclare” the functions other than having the overloads themselves~.

I will drop my pull request later ~, but you can take a look at the code there I suppose, it does imply the correct return type based on argument type~.

Edit: nevermind, I did not see the “drop promise for sync variants”. It does indeed need the redeclare since same arguments can’t have multiple return types.

1reaction
christian-bromanncommented, Mar 6, 2021

Looks good, feel free to open a PR. Too bad this can’t be referred automatically from the file and a redeclaration is necessary but I guess we have a very special case offering an API in async and sync mode.

Read more comments on GitHub >

github_iconTop Results From Across the Web

A Simple Explanation of Function Overloading in TypeScript
Function overloading in TypeScript lets you define functions that can be called in multiple ways.
Read more >
Typing Functions with Overloading, Values, and Arrow Functions
Overloading allows us to to define multiple function signatures for one function. We can think of it as pattern matching based on the...
Read more >
Improve help() by making typing.overload() information ...
With my suggested solution, help() would need to call typing.get_overloads_for() to get any overloads for the function. Unlike Raymond's suggestion ...
Read more >
Overload decorator in typings module doesn't seem to behave ...
At runtime, calling a @overload-decorated function directly will raise NotImplementedError. The correct usage of typing.overload is as follows:
Read more >
Quick guide to Function Overloading in TypeScript
For such cases, TypeScript has the handy function overloading feature. Let's see how to use it and how it can help you improve...
Read more >

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Dev.to Post

No results found

github_iconTop Related Hashnode Post

No results found