W3C home > Mailing lists > Public > public-script-coord@w3.org > July to September 2013

RE: URL API

From: Domenic Denicola <domenic@domenicdenicola.com>
Date: Mon, 8 Jul 2013 19:16:57 +0000
To: Anne van Kesteren <annevk@annevk.nl>, "public-script-coord@w3.org" <public-script-coord@w3.org>
Message-ID: <B4AE8F4E86E26C47AC407D49872F6F9F8782AD6E@BY2PRD0510MB354.namprd05.prod.outlook.com>
URLQuery API itself looks pretty solid to me. I like the `set` vs. `append` distinction.

For construction, you might want to move to the `undefined`-as-default model (ES5 built-ins and ES6 default parameter rules) instead of `null`-as-default (WebIDL as of now, I believe). So `new URLQuery(null)` should behave like `new Error(null)`; in both cases the underlying string is `"null"`. Whereas `new URLQuery(undefined)` should behave like `new Error(undefined)`, triggering the default value which is the empty string `""`.

I am curious about the distinction between `null` and "empty". Is `hash` null or emptystring for a URL without a hash segment? What about `query`: is it `null` or an empty-URLQuery for a URL without a querystring? As written I think it uses empty strings for all the string properties, whereas it uses `null` for `query`. Seems a bit inconsistent?

Somewhat-relatedly: can the parser distinguish between `?foo=` and `?foo`? It seems to me both will result in maps from `"foo"` to the empty string? Maybe the latter can map to `null`?? Otherwise how does round-trip serialization work for `?foo`? Just throwing ideas out there, not even sure if I read the spec right.

> One thing that's still a bit unclear is how to expose path segments. We could expose the segments as array, we could expose a special segments object so you can change the URL that way, or something else. Suggestions welcome.

I would be tempted to just leave it out and make people do the work manually of manipulating `pathname`, since I can't think of a great answer. Or are there potential footguns we want to avoid, e.g. if people naively did `url.pathname.split("/")` or `url.pathname = mySegments.join("/")` they wouldn't get what you expect? I guess there are some encoding issues...

> Another thing that would be nice if a URLQuery object could be populated based on a custom object or a Map. However, how we should extract the key/value pairs out of those in a way that's consistent across APIs is not really established.

In ES6 this is somewhat well-established I believe. "Map-like" iterables return iterators for `[key, value]` pairs from their `@@iterator()` internal method, and the `Map` constructor accepts such pairs, so that you can do e.g. `new Map(oldMap)` or `new Map([[1, 2], [3, 4]])`. See http://people.mozilla.org/~jorendorff/es6-draft.html#sec-15.14.1.1. I would just copy that, maybe using `"append"` instead of `"get"` to allow for `new URLQuery([["key", "value1"], ["key", "value2"]])`.
Received on Monday, 8 July 2013 19:17:33 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:37:50 UTC