Better types for UrlSearchParams

Suggestion

🔍 Search Terms

Restrictive typing on UrlSearchParams

✅ Viability Checklist

My suggestion meets these guidelines:

• This wouldn't be a breaking change in existing TypeScript/JavaScript code
• This wouldn't change the runtime behavior of existing JavaScript code
• This could be implemented without emitting different JS based on the types of the expressions
• This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, new syntax sugar for JS, etc.)
• This feature would agree with the rest of TypeScript's Design Goals.

⭐ Suggestion

declare var URLSearchParams: {
    prototype: URLSearchParams;
    // new(init?: string[][] | Record<string, string> | string | URLSearchParams): URLSearchParams;
    new(init?: 
        | string
        | URLSearchParams
        | Record<string | number, string | number | boolean | string[] | number[] | boolean[]>
        | [string | number | boolean, string | number | boolean | string[] | number[] | boolean[]][]): URLSearchParams;
    toString(): string;
};

📃 Motivating Example

The actual typing design is more restrictive than the Javascript runtime itself.

💻 Use Cases

More possibilities to create strict typed UrlSearchParams objects:

let url = 'https://developer.microsoft.com'

const queryParams = new UrlSearchParams({
  key1: ["v1", "v2"],
  key2: ["v1", "v2", "v3"]
})

url = url + '?' + queryParams // https://developer.microsoft.com?key1=v1,v2&key2=v1,v2,v3

Beginne damit, die Deklaration von URLSearchParams in der Standardbibliothek zu finden, und überprüfe deren Konstruktor-Typisierung anhand des vorgeschlagenen Overloads und der begründenden Beispiele. Sieh dir die umgebenden Typdefinitionen und relevanten Typ-Tests an, bevor du entscheidest, welche Eingabeformen unterstützt werden sollen; abgeschlossen ist die Aufgabe, wenn die Deklarationen die beabsichtigten strengeren Formen akzeptieren, ohne das erzeugte JavaScript oder das Laufzeitverhalten zu ändern.