RE: URLQuery / FormData

From: Anne van Kesteren [annevk@annevk.nl]

> I'd be interested in hearing what they have to say though.

Well, since you asked... :)

My primary concern is not deriving something from `Map.prototype` on which the `Map.prototype` methods don't work as normal (e.g., can't store objects, or setting-then-getting doesn't return the same value, or similar). But I think that's not even being considered, so I'm mostly happy. In that light, what follows is just idle musing.

My other perspective comes from working with headers and form-encoded data in Node, where their multi-valued nature is, depending on the framework, often completely broken by trying to hide it. This has made me value making it evident and obvious that multiple values can be stored for each key, as a prominent part of the API. That's why `append` was so appealing to me, leaving `set` out: it is no less convenient to use than a single-valued map's `set` would be, but it's much more clear in terms of surfacing the underlying concept.

If I found it really important to make these things conform to some sort of map structural type, I would take one of two routes:

1. Study multimap contracts in other languages, which I believe Tab is citing, and try to emulate them. (But, of course, it's not a true `Map` since it's type-restricted, so you have to adjust some stuff there.) Importantly, do other languages, preferably ones with structural types, reuse the same method names for different semantics?

  This may be a more awkward API, but perhaps re-using an awkard string-only multimap API across parts of the platform is better than coming up with a pleasant-but-conceptually-less-general API for these two use cases, or others like them. I am not sure I see the benefit, and if I were writing this library in JavaScript-as-it-is I would not try to create something general but instead serve the use case. But, it's a conceptually sound option.

2. Treat this as essentially a map of strings to arrays of strings, and add sugar methods for handling this. So, for example, `get` would return an array, `delete` would delete the whole array, `set` would reset the whole array (taking an array as a parameter), and `append` would add an element to the appropriate array at the given key (creating the entry if it doesn't exist). This is essentially your API, but with an array-taking `set` added. (Notably, we could add `set` at a later date if people really want to treat these things as maps of strings to arrays.)

---

Finally, only tangentially related: what is your plan for

```js
const q = new URLQuery();
q.append('key', 'val1');
q.get('key').push('val2');
q.get('key')[999] = 'val999';
```

? I feel like this could be made to work for composing a URLQuery meant for serialization, but would be tricky if the URLQuery is representing the browser's actual URL and changing it is supposed to change the URL. A "returns frozen arrays" mode may be necessary.

Received on Tuesday, 10 September 2013 14:44:50 UTC