Arg.js – Lightweight URL argument and parameter parser(github.com)

32 pointsby matryer13 yıl önce19 comments

Arg.js – Lightweight URL argument and parameter parser

http://github.com/stretchr/arg.js

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.

5 comments

OhHeyItsE13 yıl önce

ugh. 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?

matryer13 yıl önce

I agree actually - I prefer to keep them separate, which is why we included the hash() and query() methods too. I'd say pick one and stick with it. Arg.js has to care about both, because people use both.

mazondo13 yıl önce

well, they solve different needs, what part of it bugs you?

NathanKP13 yıl önce

The 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.

yogo13 yıl önce

My preference would be the clean, hierarchical view but there are a few filter-type scenarios where the order isn't known ahead of time or matter at all. For example a user might want to view a/b then append c/d (a/b/c/d) or vice versa (c/d/a/b). It is possible to make this with clean url but it seems like a bit more work since you might need more logic as far as parsing and routing.

Edit: pretty cool how all the sibling comments are along the same lines :)

matryer13 yıl önce

I 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) that doesn't do any routing or path parsing etc.

NathanKP13 yıl önce

Nice. 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.

paultannenbaum13 yıl önce

I 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.

NathanKP13 yıl önce

Here is how I would do it:

Assuming you were searching for computers with the following filters:

    Manufacturer: Apple
    Type: Laptop

You could represent that as:

     http://mystore.com/electronics/computers/manufacturer/apple/type/laptop

If you make your routing code (on either the frontend or the backend) robust enough then you will be able to support any number of filters in any order.

matryer13 yıl önce

for nested data - I 100% agree. I'd do that and use params for things like ordering or filtering on other fields:

    http://mystore.com/electronics/computers/manufacturer/apple/type/laptop#?order=-price&size=medium

Also - the `#` is nice for when you don't want to reload the page.

matryer13 yıl önce

URL parameters ARE RESTful and I agree that your use case is exactly where parameters are useful.

matryer13 yıl önce

... I do like the 'routing all paths to one page' idea though.

[deleted]13 yıl önce

tmzt13 yıl önce

I 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.

matryer13 yıl önce

Ohh that sounds good... I've never done it before - fancy giving me a pull request? :)

tmzt13 yıl önce

I can for composer in a few hours

mazondo13 yıl önce

been 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.

stekoz13 yıl önce

Any idea of how this compares to purl.js ? https://github.com/allmarkedup/purl

matryer13 yıl önce

We 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

matryer13 yıl önce

... and vice-versa