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
chore(types): generate our own d.ts file from api.md #3744
Conversation
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.
first pass over this wasn't scary!
@@ -1032,7 +1032,7 @@ Shortcut for [page.mainFrame().$$(selector)](#frameselector-1). | |||
|
|||
#### page.$$eval(selector, pageFunction[, ...args]) | |||
- `selector` <[string]> A [selector] to query page for | |||
- `pageFunction` <[function]> Function to be evaluated in browser context | |||
- `pageFunction` <[function]\([Array]<[Element]>\)> Function to be evaluated in browser context |
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.
escaping parenthesis is very unfortunate - why is this needed? Can we avoid this?
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.
Without it, markdown can think the function is a link. It tends not to because of syntax errors, but I'd rather not depend on it bailing out on its own.
docs/api.md
Outdated
@@ -1045,9 +1045,9 @@ Examples: | |||
const divsCounts = await page.$$eval('div', divs => divs.length); | |||
``` | |||
|
|||
#### page.$eval(selector, pageFunction[, ...args]) | |||
#### page.$eval(selector, asdf[, ...args]) |
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.
asdf!
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.
oops
Can I ask why you choose to not use TS directly? |
For this PR or for the project in general? |
The whole project, you seem to be using TS specifying type hinting in JSDoc anyways I think using TS all the way would be a better solution. |
@SimonSchick we like our current approach: we have no build step and all the benefits of first-class platform citizen (e.g. natural debugging) while having type checks. |
I setup tests for the types that run against typescript@2.1. |
* @param {!Array<!Documentation.Member>} argsArray | ||
*/ | ||
constructor(kind, name, type, argsArray) { | ||
constructor(kind, name, type, argsArray, comment = '', returnComment = '', required = true) { |
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.
can we have returnComment the same way we have arguments?
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.
while this makes the return code nicer, it makes the .type code uglier.
function parseProperty(element) { | ||
const str = element.textContent; | ||
const name = str.substring(0, str.indexOf('<')).trim(); | ||
// const firstLine = extractSiblingsIntoFragment(element.firstChild, element.querySelector(':scope > ul')); |
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.
remove
No description provided.