Posts Tagged ‘Javascript’

new Array() vs [] in JavaScript

Wednesday, February 10th, 2010

Did a little research recently about the difference between creating an array in Javascript using the array literal, or the fully qualified “object” name (Array() vs []). Here is what I found:

  • Most experienced JS programmers use []. This is what I was told by Paul Irish. When I asked Paul what he thought of a JS book I was reading, he immediately looked for an array definition (which ended up being Array() instead of []) and pointed it out as being “old fashioned”. [] is the way Douglas Crockford teaches it in JavaScript the Good Parts (they even talk about it in JavaScript the Definitive Guide). Also, if you look in the unminified source for the jQuery library, you will never see Array().
  • They appear to be nearly identical, except they aren’t.
  • [] is more terse and readable, especially for nested arrays:

    (try @ pastebin.me)

    vs:

    (try @ pastebin.me)

  • Using the Array() keyword makes you think about arrays as being somehow different from Objects (which, yes they are in-so-much as they are Objects with actual methods already defined for you). The literal helps you think about them more object-like because [] looks like {}. Plus, [] is more consistent with the way that you then access the array something[0] so there is less to remember.
  • Most importantly, Array() doesn’t behave uniformly across argument numbers and types. ((new Array(X)).length === 1 for any X as long as typeof(X) != “number” else Array(X).length === X)

Removing and re-using hard-coded onclick JavaScript methods with jQuery

Wednesday, January 27th, 2010

Let’s say you’ve been tasked with the ominous task of taking a currently “working” checkout process written in a hodge-podge of Prototype, jQuery and plain jane JavaScript and adding click methods to all input and a elements. Now, let’s also say you can’t modify the current HTML/JavaScript at all (mostly because it’s all working and you don’t want to break it and it’s already indecipherable code). Now, let’s also say that the click method you are attaching needs to be hands down, no matter what, the FIRST method that executes when you click on the element.

Sure you can make your JavaScript the first JavaScript that gets run on the page (so that the dynamic bindings run first, and therefor (hopefully) execute first). But what about the HARD CODED html click methods? This little code snippet will go through and dynamically remove (and “cache” (save for later)) all of the hard-coded onclick functions, and then bind your live functions to do your new critical must trigger first event, and then call the original onclick method on the element.

Yes, this code is scary. Yes, I cried a little after I wrote it while curled up in a ball under my desk. Yes, I plan to submit it to thedailywtf.com. But sometimes you just have to do what you have to do. If you’re in a similar situation, this might just help you out a little. Prepare to throw up in your mouth, hold on to your hats, and dive in:

To understand this a little more, you might like to throw a whole bunch of console.log() statements in there to see the state of each variable at each step along the way. It’s actually kind of fascinating that this code even works.

The toString() on the onClick on the attr call actually returns:
"function onclick(e){doThing();}

This is scary/cool/weird since the attribute it’s pulling is just
<input type="checkbox" onclick="doThing()" />

So I go through with the regex and strip off the “ onclick” leaving just an anonymous function: “function(e){doThing();}

I then assign the anonymous function to the variable “clickMethod” thus creating a brand new function on the page called clickMethod, which can be triggered or called anywhere I want and even passed an event object!!!

*BARF* XP

Someone please tell me there’s a better way… If so, why not hook me up on FIXEE???

TOTW: Google Closure JavaScript Compiler Web Interface

Monday, January 25th, 2010

This week’s Tool of the Week is Google Closure JavaScript Compiler. I know everyone has probably heard of it, but if you haven’t gotten around to checking it out, this post is great for you.

What it does:

Allows you to compile JavaScript down to a compressed form. It reads in your JavaScript, parses it, and re-writes it to be much smaller. This is good for you because it will make your site load faster, much faster in some cases.

When you need it:

  • To compress your JavaScript
  • To combine multiple JavaScript Files

How to use it:

The Example:

Additional Notes:
Notice in the compile directions there is an @output_file_name parameter. You can change this to something other than “default.js” (you can name it anything you want. Then you can actually access the results by clicking on the link on the right hand pane that says “The code may also be accessed at default.js” (if you rename it it will put the name you put instead of default.js). Here’s the file generated by my example.