New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
removal of the chainable promise types #12386
base: main
Are you sure you want to change the base?
removal of the chainable promise types #12386
Conversation
export interface ChainablePromiseElement<T> extends | ||
ChainablePromiseBaseElement, | ||
AsyncElementProto, | ||
Promise<T>, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was thinking of only removing the Promise<T>
part. I am not sure if removing ChainablePromiseElement
would be a good idea.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I find that my colleagues have no clue what ChainablePromiseElement
is and therefore just await
it anyway and I cannot blame them. I think having WebdriverIO.Element
as type makes much more sense, what do you think?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think the noticeable difference is that:
const chainablePromiseElement = $('elem')
console.log(chainablePromiseElement.selector) // outputs: "Promise<string>"
whereas:
const wdioElement = await $('elem')
console.log(wdioElement.selector) // outputs: "elem"
So I am not sure if we can merge this into one single type since the chainable element is not resolved and accessing properties requires to use await
. I can see that ChainablePromiseElement
is confusing and I am in favor to consolidate this. Any suggestion how we can overcome the type difference?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Interesting, does this mean that you need to await
the $
command when accessing any properties but not when you want to execute an action later or chain it with another $
or $$
directly?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Correct. You can do $('elem').$('elem').$('elem').$('elem')
as our proxy command wrapper allows to chain these promises.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I believe you can extend the type to check if it has the elementId and if not you can assign it a Promise like type. I knowledge of Typescript is not where I want it to be so I might get a course on it to learn about more complex types 👍
Proposed changes
Based on a talk I had with Christian and my current team I decided to update our types to reflect that you do not need to
await
the$
and$$
commands.I have replaced the types with TypeScript's
Awaited
utility type: https://www.typescriptlang.org/docs/handbook/utility-types.html#awaitedtypeTypes of changes
Checklist
Reviewers: @webdriverio/project-committers