Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
URI.js expects users to do their own URI-encoding, thus defeating its own purpose #79
URI("").segment(["%"]); // => URIError: URI malformed URI("%25").segment(); // => ["%25"]
This makes me want to cry.
The whole point of having a library to handle URIs is that the user of the library shouldn’t have to think about how to encode or decode URIs.
For example, if I know that there is a resource called “Business Plan (90%)” in a directory called “My Extremely Dull Documents”, I ought be able to create a relative URI referencing that resource with syntax somewhat like this:
URI("").segment(["My Extremely Dull Documents"], ["Business Plan (90%)"]);
which would then produce a URI whose text representation is:
Similarly when parsing the resulting URI I ought to be able to do something somewhat like:
And get back the original strings:
I know I can use
What do you suggest we do about this then?
Yeah, I deliberately stopped short of proposing a specific solution because I’m aware of the problem you point out, and I didn’t want to distract from the broader point.
One possible solution is to acknowledge that just as a URI is a data structure, so many URI components are themselves data structures and should be treated as such. So, for instance,
Another solution is to do something similar to what you’ve done for query parameters. The
I think we can leave
That just leaves the problem of backward-compatibility. I do not want to add another (boolean) parameter to the signature. So we'd probably be left with exposing a new method. Ideas for a name?
I don't want to deprecate
So, I'd propose we do the same thing to