$.url() - A simple, lightweight url parser for jQuery

https://github.com/websanova/jquery-url#url

by rduchnik • 14 years ago

98 39 14 years ago

prezjordan• 14 years ago

I like, but I'm curious why this is a jQuery plugin.

tcas• 14 years ago

Looking at the source, it looks like there's only one line that calls jQuery on line 37 (and I don't think it should be using the short calling convention without a wrapper -- if you rename jQuery to '_' or something else it won't work):

    else if($.isNumeric(arg)

There's no native JavaScript equivalent to it if I recall correctly, but there's a bunch of alternatives to it as well.

It should be easy enough to extract out the logic and repackage it. Maybe I'll fork it tomorrow and do the changes myself.

ville• 14 years ago

I think a good alternative would be just to accept a number. url(1) instead of url('1')

davecardwell• 14 years ago

jQuery simply does this:

  isNumeric: function( obj ) {
    return !isNaN( parseFloat(obj) ) && isFinite( obj );
  }

csarva• 14 years ago

No clue, but it's nice to have a namespace for it, rather than mucking up the global context with a simple utility method. Might be better off shimmying up to underscore (perhaps only if it's already detected, otherwise go global?), however there are lots of similar jquery 'plugins' of this nature..

bmuon• 14 years ago

Modules are the way to go, not polluting an arbitrary namespace.

mmcnickle• 14 years ago

I presume to allow for idiomatic use in code that already uses a lot of jQuery:

    var file = $('a#interesting').url('file')

    var file = url($('a#interesting'), 'file');

rane• 14 years ago

I don't see what DOM has to do with URL parsing.

languagehacker• 14 years ago

Good job. JavaScript has needed something like this for a while. I'm still kind of confused as to why they don't have good native support for URL parsing.

DrJokepu• 14 years ago

You might find this useful: https://developer.mozilla.org/en-US/docs/DOM/window.location...

taf2• 14 years ago

to quote my favorite seen from the lion king reference: "http://www.imdb.com/character/ch0000591/quotes "look harder". You can parse URL's in JavaScript using window.location or anchor.href, both provide solutions for parsing URL's... someone else from this thread referenced: http://stackoverflow.com/questions/6168260/how-to-parse-a-ur... (above i believe)...

Almaviva2• 14 years ago

.. and I still have to roll my own library or inline code for parsing apart GET params. No thanks.

septerr• 14 years ago

Nice. And prezjordan has a good question. Why is it a jquery plugin?

solox3• 14 years ago

If the url doesn't contain the required component, it will throw errors. Why not return an empty string like urlparse does?

bitsm• 14 years ago

Just FYI, most, if not all, of this is built into javascript already, via the DOM. http://www.joezimjs.com/javascript/the-lazy-mans-url-parsing...

yahelc2• 14 years ago

Agreed, this is the way to do it. The only caveat is that IE has a bug where it omits the leading / on the pathname. You can normalize it with a simple one-liner: http://stackoverflow.com/a/6168370/172322

lloeki• 14 years ago

> Agreed, this is the way to do it.

This sounds like arguing that we should use getElementById&al, addEventListener, and array.length with for loops instead of $('selector').on 'foo' and .each(). While this lib's inner code leaves to be desired in a number of ways, I really appreciate the readability and the lack of need to instantiate a full-blown DOM element then read a property to obtain a simple single result or two.

lowboy• 14 years ago

This was my initial reaction as well, but I appreciate the qs/hash sugaring:

    http://www.domain.com/path/index.html?query1=test&silly=willy#test=hash&chucky=cheese
    
    $.url('?');         // query1=test&silly=willy
    $.url('?silly');    // willy
    $.url('?poo');      // (an empty string)
    $.url('#');         // test=hash&chucky=cheese
    $.url('#chucky');   // cheese
    $.url('#poo');      // (an empty string)

mistercow2• 14 years ago

I think that's a bit too much functionality to put down as "sugar".

tjholowaychuk• 14 years ago

this has nothing to do with jquery, stop the madness! haha

https://github.com/component/component/wiki/Building-better-...

https://github.com/component/url

Jare• 14 years ago

Nice little utility, just a couple of issues that should be easy to fix:

- Breaks for protocols other than http/https, including protocol-relative urls.

- Breaks query string values that contain '='.

dudus• 14 years ago

Extracting Host, Subdomain and TLD from a url is hard. And they clearly oversimplified it.

  $.url('host', 'http://www.google.com.br');  // 'com.br'
  $.url('sub',  'http://www.google.com.br');  // 'www.google'
  $.url('tld',  'http://www.google.com.br');  // 'br'

It will work for simple cases where the TLD has only one field like (www.google.com) or (www.usa.gov), but it will fail for any other tld with country codes.

mistercow2• 14 years ago

That is partially incorrect. There is no such thing as a TLD with more than one field. In "http://www.google.com.br, "br" is, in fact, the TLD, while "com" is the SLD[1]. So the 'tld' behavior is fine.

The "sub" behavior is awkward, however. It would make more sense to just have a numeric way of accessing the domain parts by index, just like they do with extracting the path elements.

As for "host", well that is just completely the wrong behavior. Since the parameter is "host", you would expect that to give the hostname. But the hostname corresponding to an internet URL is simply the fully qualified domain name. I have no idea how the behavior implemented would be useful in the first place, but it certainly shouldn't be called "host".

[1] http://en.wikipedia.org/wiki/Country_code_second-level_domai...

snowwolf• 14 years ago

Domain parsing is hard. PublicSuffix service seems to be the best way of doing it. http://stackoverflow.com/questions/288810/get-the-subdomain-...

BinaryBullet• 14 years ago

As others have suggested, jQuery is overkill for this.

The best lightweight js library I've found/used in the past is parseUri:

http://blog.stevenlevithan.com/archives/parseuri

Obviously, if you only need to analyze the current URL, you can use window/document.location, but there are times when you want to parse a URI for a page you aren't on. For instance, if you are analyzing har data, and want to break URI "components" into columns so they are sortable.

Almaviva2• 14 years ago

I have a hard time seeing why, these days, an extra 1.2k for something that makes a task simpler and more consistent is ever "overkill".

joesb2• 14 years ago

jQuery is not 1.2k.

And this library doesn't have a strong reason to tie itself to jQuery. It doesn't need jQuery's DOM operation or AJAX. It's like making a program depending on third party library without actually using any of the feature.

barefoot• 14 years ago

Thanks for having the link go directly to examples.

wslh• 14 years ago

How it compares against http://code.google.com/p/jsuri/ ?

valentinu• 14 years ago

I would be interested too to see a comparison with jsuri. I was about to say that jsuri is not maintained anymore but looking closer on http://code.google.com/p/jsuri/ I saw that now the project is active on github: https://github.com/derek-watson/jsUri with the latest version being 1.2.2

theozaurus• 14 years ago

There's also an attempt I made, https://github.com/theozaurus/jsurlify which tries to keep the usage as terse as possible. It would be great to see what strengths / weaknesses all these different libraries have and try to join efforts where sensible.

vhiremath4• 14 years ago

I have OCD about code cleanliness... No semicolon at the end of line 26? Please excuse me as I proceed to gag.

But me being a douche aside, I'm not sure why you needed to extend from/bake into jQuery for this.

adulau• 14 years ago

Parsing url is difficult and prone to errors. How $.url() compares to furl? There are two furl(s) on github:

(1) https://github.com/stricaud/furl

and

(2) https://github.com/gruns/furl

furl(1) seems to handle a lot of edge cases when the URL is containing an IPv4/IPv6 address or when the URL is partial (e.g. without the protocol). furl(1) aims is to be fast. furl(2) seems to be more flexible and used for inline modification of the URL.

stricaud• 14 years ago

I actually renamed the furl project into faup, for 'Finally An Url Parser' ;-) That should solve the problem. API and command line tool will follow.

Hovertruck• 14 years ago

It looks like this has been moved and is no longer a jQuery plugin, which is awesome. It's now, however, creating a global variable named `url` which is dangerous to say the least.

rduchnik• 14 years ago

Well I really wasn't expecting this much feedback for this little library. I threw it up for kicks and went out for a movie, when I came back I was surprised to see all the interest. It's just a simple parser I wrote for my projects, so it doesn't get too crazy with exact definitions of "tld" and support for IPv4/IPv6 addresses as mentioned in the comments. Might be better to create a secondary more heavyweight version for things like that.

Anyway, I've fixed/updated a bunch of things from the comments, if anyone finds any other bugs or missing features probably best to leave me an issue on the github project page here: https://github.com/websanova/js-url/issues.

The project has also been un-jquery-ified and renamed to js-url (thanks to Jay Adkisson : https://github.com/jayferd)

Thanks

$.url() - A simple, lightweight url parser for jQuery

Related Stories