-
-
Notifications
You must be signed in to change notification settings - Fork 49
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
Add TypeScript definition #68
Conversation
index.d.ts
Outdated
* | ||
* @param window - Default: BrowserWindow.getFocusedWindow() | ||
*/ | ||
export function refresh(window?: Electron.BrowserWindow): void; |
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.
Couldn't you use a default parameter here?
export function refresh(window?: Electron.BrowserWindow = BrowserWindow.getFocusedWindow()): void;
Then line 43 would be moot.
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.
Hm, the default value doesn't seem to show up in the inline docs preview when using this syntax.
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.
But it’s valid syntax, right? If so, I think we should still use it and open an issue on VSCode about it.
Instead of using the import {BrowserWindow} from 'electron'; |
index.d.ts
Outdated
* win = new BrowserWindow(); | ||
* }); | ||
*/ | ||
export default function electronDebug(options?: Readonly<Options>): void; |
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.
Hmm, I think we should use readonly
on the specific properties whenever possible, as Readonly
will show up in the code completion and create noise:
Maybe that's a non-issue. I dunno.
Thoughts?
*Really want the readonly
type operators...
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'm not sure either…
Is that information useful in any way to the end user of the API? If it's not, then sure, readonly
all the props. 😉
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.
It’s not. It’s only useful for us to ensure we don’t modify the object.
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.
Let’s go with per-property annotation.
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.
*Really want the
readonly
type operators...
Btw. TS seems to be slowly closing in on that… 😅
microsoft/TypeScript#29435
microsoft/TypeScript#29510
Not quite there yet, but I like the trajectory. 😉
#68 (comment) doesn't actually work... I'm getting the error:
Seems it's not allowed in ambient context... Which sucks. I ended up with this: 142b2de#diff-b52768974e6bc0faccb7d4b75b162c99R52 I tried |
I also realized another thing. There actually isn't really any point in using |
It basically acts as a blueprint for the potential conversion to TypeScript. Or a source of "truth" about the code, even if not enforced by the tooling. 🤷♂️ |
Hmm, yeah, I guess. Alright, let's keep it for now. |
Closes #66