URLSearchParams API should accept numbers for values

Actual implementation of `URLSearchParams.constructor` and `URLSearchParams.prototype.set` methods in the browsers will accept any value as value, including number or Integer. TLDR: `new URLSearchParams([['foo', 1]])` and `new URLSearchParams().set('bar', 1)` should compile without TS errors It works in current implementation, because numeric value will be coerced to actual `USVString` value, which is a `string`. Unfortunately, current TS definition of type `URLSearchParams` in `lid.dom.d.ts` will only allow strings for above mentioned setters. Below are the definitions. I can understand that the definitions are mirroring the [W3C specifications](https://url.spec.whatwg.org/#interface-urlsearchparams) but I do believe it is not the expected experience for developers. The actual definition enforces developers to make unnecessary operations (helpers / utils / map-reduces) to overcome TS errors 👋 Can we reconsider to allow values to be numeric to mentioned setters? This won't break any current bahavior or actual implementation. Even as per MDN examples [constructor](https://developer.mozilla.org/en-US/docs/Web/API/URLSearchParams/URLSearchParams#Examples) and [URLSearchParams.prototype.set](https://developer.mozilla.org/en-US/docs/Web/API/URLSearchParams/set#Examples) it should work as expected: ```js // Pass in a sequence var params3 = new URLSearchParams([["foo", 1],["bar", 2]]); //Add a third parameter. params.set('baz', 3); ``` Which works in browser but doesn't

Posted by artyil on Aug 17, 2019, 12:25 PM

Tags

• github (Other)

Related issues

• struct's lifetime requirements can be bypassed via covariant field assignment
• Proposal to Reorganize the Moderation Team and Review Moderation Policies
• Progressive FPS degradation appears to be related to dota2.com — blocking the domain prevents the performance loss
• proposal: container/...: generic collection types
• Better Custom Endpoint BYOK
• A concrete policy for backward compatibility until Godot 5.0