Skip to content

fix: update alert method signature to accept string type #2006

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

Merged
merged 1 commit into from
Apr 27, 2025

Conversation

Bashamega
Copy link
Contributor

I have updated the alert method to take a string.
fixes #1626

Copy link
Contributor

Thanks for the PR!

This section of the codebase is owned by @saschanaz - if they write a comment saying "LGTM" then it will be merged.

@@ -718,7 +718,7 @@
"method": {
"alert": {
"overrideSignatures": [
"alert(message?: any): void"
"alert(message?: string): void"
Copy link
Contributor

Choose a reason for hiding this comment

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

In this case we can just remove this whole method. But have you checked why this is added?

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 have checked it, and the message is required by default. But the alert works even if it isn't required.

Copy link
Contributor

Choose a reason for hiding this comment

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

Really? It seems it has been like that forever without a documented reason though. c9dcdfd

Anyway, please remove the whole method overridding and it'll become string.

Copy link
Contributor

Choose a reason for hiding this comment

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

Err, actually the spec makes it multiple overloads instead of using an optional param. For now let's just do this.

@saschanaz
Copy link
Contributor

LGTM

Copy link
Contributor

There was an issue merging, maybe try again saschanaz. Details

@jakebailey
Copy link
Member

MDN implies that passing in a non-string is okay: https://developer.mozilla.org/en-US/docs/Web/API/Window/alert#message

Maybe it's fine to be stricter, but I am wondering if it's worth it.

@saschanaz
Copy link
Contributor

Passing a non-string is always okay for any string parameter because everything will implicitly be stringified. Except most objects have no overriden stringifier and will just give [object Object], which is something TypeScript wants to prevent.

@saschanaz
Copy link
Contributor

(and this follows prompt() and confirm() for consistency)

@jakebailey
Copy link
Member

In general I agree, but alert does explicitly mention the conversion while prompt and confirm don't, which is why I mention it.

@saschanaz
Copy link
Contributor

Those all use the same IDL DOMString though? What MDN says is just whatever the human editor decided to write, and given the documentations are not automated, it's very expected to not say super consistently for the same things.

@jakebailey
Copy link
Member

jakebailey commented Apr 27, 2025

That's fair, I was just foreseeing someone going "I can't alert with number anymore!"

@saschanaz
Copy link
Contributor

saschanaz commented Apr 27, 2025

That foreseeing is fair too, and perhaps someone may quote MDN the same way you did. I can't imagine an actual production-ready web page would have alert(1) for real thing though, let alone alert() itself not being recommended because of being synchronous.

For now I'd vote for consistency, but we can still see whether this really breaks anything and reconsider.

LGTM

@github-actions github-actions bot merged commit 3263db8 into microsoft:main Apr 27, 2025
11 checks passed
Copy link
Contributor

Merging because @saschanaz is a code-owner of all the changes - thanks!

@Bashamega
Copy link
Contributor Author

That's fair, I was just foreseeing someone going "I can't alert with number anymore!"

If that occurs I can add make it accept numbers

saschanaz added a commit to saschanaz/types-web that referenced this pull request May 5, 2025
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.

Inconsistent signatures for alert() vs prompt()/confirm()
3 participants