Skip to content
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

types: better types #1166

Merged
merged 14 commits into from
Mar 20, 2020
Merged

types: better types #1166

merged 14 commits into from
Mar 20, 2020

Conversation

JoelEinbinder
Copy link
Contributor

#6

A place for discussion

@JoelEinbinder JoelEinbinder requested review from dgozman and pavelfeldman and removed request for dgozman February 29, 2020 00:37
@JoelEinbinder
Copy link
Contributor Author

JoelEinbinder commented Feb 29, 2020

@dgozman comments
In events:

  • arg0: void should be ()
  • arg0 should be camelcase type name
  • overrides of interface types
  • enums somehow
  • combine as many types as possible
  • parser broke on FirefoxBrowser events
  • page being templated is ugly
  • tag names are not needed
  • HTMLElement/SVGElement by default

@JoelEinbinder
Copy link
Contributor Author

  • I'll try to do enums in a follow up, they are difficult.
  • Combining types makes it hard to guarantee no breaking changes. In a follow up, ill try to move a lot of our duplicates into aliases though, which should make things more readable.
  • I kept the tags because I like them a lot.

@JoelEinbinder JoelEinbinder marked this pull request as ready for review March 4, 2020 01:43
export const chromium: import('./lib/server/chromium').Chromium;
export const firefox: import('./lib/server/firefox').Firefox;
export const webkit: import('./lib/server/webkit').WebKit;
export const selectors: import('./lib/api').Selectors;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What about selectors, web, errors and devices?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is web public right now? How is it accessed? I did the others.

@@ -30,9 +30,10 @@
"wcoverage": "cross-env COVERAGE=true BROWSER=webkit node test/test.js",
"tsc": "tsc -p .",
"clean": "rimraf lib",
"build": "node utils/runWebpack.js --mode='development' && tsc -p .",
"build": "node utils/runWebpack.js --mode='development' && tsc -p . && npm run generate-types",
"watch": "node utils/runWebpack.js --mode='development' --watch --silent | tsc -w -p .",
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we need something for watch?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure. I don't think it works right now in build though. It depends on the protocol.ts file to be generated, but the protocol generator requires the project to be built. I'll move it to a separate command that runs on bots, test, and before publishing.

utils/generate_types/index.js Show resolved Hide resolved
utils/generate_types/overrides.d.ts Outdated Show resolved Hide resolved
utils/generate_types/overrides.d.ts Show resolved Hide resolved
utils/generate_types/parseOverrides.js Show resolved Hide resolved
utils/generate_types/test/test.ts Outdated Show resolved Hide resolved
utils/generate_types/test/test.ts Outdated Show resolved Hide resolved
utils/generate_types/test/test.ts Outdated Show resolved Hide resolved
utils/generate_types/index.js Outdated Show resolved Hide resolved
@JoelEinbinder
Copy link
Contributor Author

I think this is ready for another look!

Copy link
Contributor

@dgozman dgozman left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Overall looks good. Could you please post a gist with generated types?

utils/generate_types/overrides.d.ts Show resolved Hide resolved
type ElementHandleForTag<K extends keyof HTMLElementTagNameMap> = ElementHandle<HTMLElementTagNameMap[K]>;

type WaitForSelectorOptionsNotHidden = PageWaitForSelectorOptions & {
visibility: 'visible'|'any';
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This has been changed recently.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Unfortunately my tests for this didn't catch it somehow. I don't know how to make them more strict, but I fixed it.

utils/generate_types/overrides.d.ts Outdated Show resolved Hide resolved
@JoelEinbinder
Copy link
Contributor Author

@dgozman
Copy link
Contributor

dgozman commented Mar 12, 2020

https://gist.github.com/JoelEinbinder/d5086a918a7886fdfc2f9d6dafb29623

  • FirefoxBrowser overrides disconnected event.
  • WebKitBrowserNewPageOptions.ignoreHTTPSErrors allows null value, but we actually don't expect that, only undefined. Same with other options.
  • Will you follow up with declaring type FirefoxFooOptions = GenericFooOptions?
  • Many option fields have JSDoc not starting with capital letter. Perhaps we should fix the docs?
  • I am surprised with BrowserContextSetHTTPCredentialsOptions. Do we call any object parameters "Options"? Do we ever have two object parameters?
  • ElementHandleTripleclickOptionsOffset has optional x and y, should be required.
  • PageFilechooserPayload is defined 3 times.

JoelEinbinder added a commit that referenced this pull request Mar 18, 2020
Currently in our API `?` means null, but sometimes it means optional. Linting optional/nulls with this patch is required for #1166 to land nicely.

Previously, return types were not being linted in `api.md`. This is fixed, along with many broken return types.

This patch considers `?` to mean nullable, and has some heuristics to determine optionality. I believe this to be the minimal patch needed to unblock #1166. After it lands, we can consider changing the api docs to hopefully remove some heuristics and strangeness.
@JoelEinbinder JoelEinbinder force-pushed the d_ts branch 2 times, most recently from 461e4dc to f5c458c Compare March 19, 2020 21:49
@JoelEinbinder
Copy link
Contributor Author

Ready for another look!

New gist: https://gist.github.com/JoelEinbinder/4d69cd5373d00443c1b5efa72ae114bd

  • FirefoxBrowser overrides disconnected event.

Done

  • WebKitBrowserNewPageOptions.ignoreHTTPSErrors allows null value, but we actually don't expect that, only undefined. Same with other options.

Done via #1206

  • Will you follow up with declaring type FirefoxFooOptions = GenericFooOptions?

Yes

  • Many option fields have JSDoc not starting with capital letter. Perhaps we should fix the docs?

English review of the api is up next. I'll fix it then.

  • I am surprised with BrowserContextSetHTTPCredentialsOptions. Do we call any object parameters "Options"? Do we ever have two object parameters?

I was using 'Options' everywhere. I changed it to the argument name. This works better everywhere except for PageWaitForEventOptionsOrPredicate, but for the sake of consistency I'm not going to worry about that.

Note that this means changing the argument names could be a breaking change, because the types will change.

  • ElementHandleTripleclickOptionsOffset has optional x and y, should be required.

Done via #1206

  • PageFilechooserPayload is defined 3 times.

Done

@dgozman
Copy link
Contributor

dgozman commented Mar 20, 2020

  • I am surprised with BrowserContextSetHTTPCredentialsOptions. Do we call any object parameters "Options"? Do we ever have two object parameters?

I was using 'Options' everywhere. I changed it to the argument name. This works better everywhere except for PageWaitForEventOptionsOrPredicate, but for the sake of consistency I'm not going to worry about that.

Note that this means changing the argument names could be a breaking change, because the types will change.

I don't like this restriction. Let's brainstorm and follow up.

Copy link
Contributor

@dgozman dgozman left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's land it!

@@ -48,7 +48,7 @@ interface TestSetup<STATE> {
MAC: boolean;
LINUX: boolean;
WIN: boolean;
playwright: import('../src/server/browserType').BrowserType;
playwright: import('../src/server/browserType').BrowserType<import('../src/browser').Browser>;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's migrate this whole file to public types in a follow up.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Definitely!

const objectDefinitions = [];
const handledMethods = new Set();
/** @type {Documentation} */
let documentation;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

WDYT about slowly rewriting all our utils into typescript? Having types will definitely help.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We have types through JSDoc. I'm always against typescript, so I am biased. With the utils, is harder because the utils will depend on the library to be built and the library depends on the utils to be built, so you end up needing to require the npm playwright as a devDependency of playwright or having separate bootstrap logic. I'd rather avoid it.

@JoelEinbinder
Copy link
Contributor Author

  • I am surprised with BrowserContextSetHTTPCredentialsOptions. Do we call any object parameters "Options"? Do we ever have two object parameters?

I was using 'Options' everywhere. I changed it to the argument name. This works better everywhere except for PageWaitForEventOptionsOrPredicate, but for the sake of consistency I'm not going to worry about that.
Note that this means changing the argument names could be a breaking change, because the types will change.

I don't like this restriction. Let's brainstorm and follow up.

Filed as #1439

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants