5 ms·
Arg.js – Lightweight URL argument and parameter parser
Everything that existed for this was bloated or weird. Arg.js is our attempt at keeping it simple and solving the problem in an elegant way.
- mazondo 13y agobeen using this for a few days now. Simple to use and solves a common frustration, I've added it to my standard base app install. Edit: base, not bass...silly me.
- stekoz 13y agoAny idea of how this compares to purl.js ? https://github.com/allmarkedup/purl https://github.com/allmarkedup/purl
- matryer 13y agoWe just thought it did too much for what we needed. It's a great library, and if I were parsing URLs in my apps I'd use it. But we just wanted a single get() interface and support for complex objects in the URL. Arg.js turns an object like this: { tags: ["one", "two", "three"], deep: { nested: { objects: true } } } into this: #?tags[0]=one&tags[1]=two&tags[2]=three&deep.nested.objects=true
- matryer 13y ago... and vice-versa
- OhHeyItsE 13y agough. I know that popular convention is pulling so, so hard in this direction. But, am I the only one around here who thinks that mashing query strings and document fragments into the same namespace is a Bad Idea?
- deleted 13y ago[deleted]
- NathanKP 13y agoThe library looks very nicely done, however, personally I think it is better to avoid such query string parameter formats completely. So to use an example from the Github page: http://www.stretchr.com/?name=Mat&company=Stretchr#?comment=123 should become http://www.stretchr.com/companies/Stretchr/users/Mat/comments/123 The URL now looks much nicer and more readable, and it also leads to organized hierarchy because of predictable URL patterns. So maybe the user wants to see the list of all users in the Stretchr company. So just from the URL they can determine that a good way to do that is probably by removing the end of the URL so that it is: http://www.stretchr.com/companies/Stretchr/users Anyway, that's just my personal preference, but I think that query string style URL's should be avoided unless absolutely necessary and nicer REST style URL's should be used instead. If you have a one page app you can route all requests on the domain to one page, and then use Backbone logic to look at the REST style URL and show the correct view based on the URL.
- matryer 13y agoI love that style too actually - and always prefer it when I can. Sometimes, you just need parameters. But more and more I'm writing apps with no backend (Stretchr makes it easy to do so) in just HTML5 and JavaScript... and serving pages like that tends to be more difficult. I use a simple web server (like Thru http://github.com/stretchr/thru http://github.com/stretchr/thru) that doesn't do any routing or path parsing etc.
- NathanKP 13y agoNice. I'm a big fan of little to no backend as well. I've done a similar simple web server in Node.js which does nothing but check to see if a static file exists to serve the request. If so it serves that static file. If not then it serves the index.html page. The index.html page then has Backbone logic to parse the URL and serve a proper view based on what the URL is. It matches up nicely with the REST style URL's and you still don't need a heavy backend to do routing that way.
- paultannenbaum 13y agoI agree if everything in your app follows a perfectly restful pattern, but what about if you want to capture application state that does not belong in a database. For example, what if you have an online store that has many different filters to narrow down selections. And you want to share this url with someone. How would this be done using a RESTful url path? You have to use url params. If so, this seems to be a nice solution if your using a lot of params.
- tmzt 13y agoI would suggest adding a bower and composer package file, it's so nice to pull in a library like and just start using it without the additional tooling.