Improve typings by using function overloads
See original GitHub issueThe 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:
- Created 3 years ago
- Reactions:4
- Comments:9 (8 by maintainers)
Top 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 >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
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.
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.