fragmentURI methods for working with single page apps

[mark-rushakoff]

This library looks really good except for the fact that it didn't offer much utility in working with single page applications (e.g. using Backbone Router or Sammy.js). You can work around this by extracting the fragment from the URI, making a new URI from that, modifying it, and plugging it back into the fragment of the original URI; or you could use the helper methods I added in this pull request.

Tests are included, but documentation isn't. If the code meets your standards, I will be happy to update the pull request with changes to the documentation files as well.

[rodneyrehm]

I already have more requests lined up for fragment-abuse. Thank you for your input!

I currently have requests for three "competing" fragment-abuse "standards":

• Google AJAX Shebang
• Backbone Routing
• Fragment-Parameters #?foo=bar&baz=2

Google's abuse starts with #!, Fragment-Parameters start with #?, Backbone Routing has no simple identification I can see at the moment.

Are there any other "standards" URI.js should handle in one way or another?

[mark-rushakoff]

I've only used Backbone for this situation -- Backbone is nice because it doesn't force you into any convention other than having a leading #. As far as I can tell, Sammy.js does the same.

I didn't cover having only fragment-parameters in my tests. I'm not sure whether that would work correctly without some changes. But I doubt that the presence of a ! would be restored correctly in a reassemble... so maybe fragmentURI should take an optional parameter specifying a prefix?

[rodneyrehm]

I'm still uncertain how to handle this. Looking at your patch, It's nothing that can be done from the outside (for the time being). I'd like to think about fragment-abusal some more… (if anyone has any opinions on the matter, please chime in!)

[marcalj]

Mmm, probably a deparam function foo=bar&hola=adeu --> {foo: 'bar', hola: 'adeu'}. :)

In "search" or hash zone will apply...

[rodneyrehm]

I was actually thinking about fragment-abuse not being a standardized thing. Anyone could do anything with the fragment. Storing data, other URLs, counting kittens…
The "deparam" you're talking about is URI.parseQuery() - it would be a matter of minutes having fragment use that. But the point is, .addQuery() and .removeQuery() are first level citizens mutating the query string. We would have to add addFragmentQuery() and removeFragmentQuery() to allow the same for fragments. API explosion up ahead…

[marcalj]

Oh, thanks :)
Good question... and something like: addQuery(data, 'fragment'); ?

[rodneyrehm]

addQuery(string_name, string_value, boolean_doNotBuild) and addQuery(object_data, boolean_doNotBuild) are the current signatures. this is getting messy :(

[rodneyrehm]

I've come to the conclusion, that fragment abuse is done in too many different ways. I don't see a singular API for the matter. I'm not going to push any fragment abuse into the "core" (unless it was "standardized" somewhere).

That said, I've added src/URI.fragmentURI.js and src/URI.fragmentQuery.js to demonstrate the process of enabling URI.js to do what you expect it to. I'll have to write some more doc on the matter, though.

This way anyone can do their own custom hash thingy… agree?

[mark-rushakoff]

@rodneyrehm Offering an example of "here's one way you could handle fragment URIs" seems like a very reasonable compromise IMO. It directly addresses the two-part problem of "there's no standard way to handle fragment URIs" and "there wasn't an obvious place to extend URI.js to handle your own fragment URIs." It gets my vote of approval!

[rodneyrehm]

awesome… If you have some words to share for the docs please do so. :)