W3C home > Mailing lists > Public > public-script-coord@w3.org > January to March 2016

URLSearchParams: calling .set() and .append() should return itself

From: Marcos Caceres <marcos@marcosc.com>
Date: Mon, 29 Feb 2016 19:21:14 +1100
To: public-script-coord <public-script-coord@w3.org>
Message-ID: <etPan.56d3ff7a.7e26a53e.3348@Zero-privacy.local>
Hi, 
Below is a replay of https://github.com/whatwg/url/issues/90 

Just wanted to get some input from public-script-coord on the following. Annevk, tells me that "This pattern of returning this is not something TC39 is still advocating I believe. That's why we didn't copy it. It makes it impossible to introduce a useful return value in the future." 

Could I kindly ask for some clarification or a pointer from TC-39 members? If not returning the object, is there a new pattern?

From #90: 

Given a list of search params (strings) to be inserted into a URLSearchParams object, it would be useful if calling .set() and .append() would return the instance of URLSearchParams. Two reasons:

    URLSearchParams, although not "map-like", is extremely close to an ES Map in look and feel. ES Map() returns itself when a developer calls set(). Similarly, so do the calls on ES Set(). It is surprising that URLSearchParams does not work the same.
    Using listOfURL.reduce() (or other functions that operate on lists that expect an object in return) would benefit from this.

Consider, this would allow the following code:

function buildQuery(items) {
  const params = new URLSearchParams();
  items
    .map(item => item.url)
    // This is not great, requires unnecessary "{ }", ";" x2, and "return"  :(
    .reduce((params, url) => {
       params.append("foo", url);
       return params;
    }, params)
  return params.toString();
}

Could become much cleaner:

function buildQuery(listOfThings) {
  return items
    .map(listOfThings => listOfThings.url)
    .reduce((params, url) => params.append("foo", url), new URLSearchParams())
    .toString();
}
Received on Monday, 29 February 2016 08:21:37 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:25 UTC