An article about flickrs pre-script event handler

gistfile1.txt

Production Tear Down 

How does flickr handle the problems of loading scripts asynchrounsly.

Wether, or not you are using an asynch loader, or you are puting your script loading at the bottom of your dom you have a problem. In some cases your scripts will load after the user has clicked on something that requires there to be a javascript function to handle the click. 

If you have built out a fully accessible site you might have a non-js flow, but that is usually substandard if the user has javascript, and it just is taking to long for your scripts to load. What you need some way of handling events before all of your scripts have finished loading.

First we I am going to take a look at how flickr does this, and then I want to break down a more generic way of doing this.

Flickr actually loads quite a lot of scripts before the main body of there code. The key code here is there.

https://gist.github.com/1394593

Some quick things here F is the global flickr object that contains all of flickrs javascript. This technique is widely taught, and accepted at Yahoo. As well as the rest of the world. By keeping all of your sites functionality in one global object you are not polluting the global namespace. It also is a great way to organize your code.

A core idea behind this code is that you don't care about every event, and you don't need to completely handle every event. Though, you might want to run some code in between the time that the click event is fired, and when the module that can handle the event is loaded, this is called the interim function. Finally, you can register some code to ran once the module is loaded, this is called a cleanup callback.

So the first step is to register a click_queue handler. An easy one to see in action is the fav button handler.

You can see that in the un-faved state the star is not highlighted

http://dl.dropbox.com/u/133599/Screenshots/x1jg.png

Once you have liked it you can it will turn purple.

http://dl.dropbox.com/u/133599/Screenshots/_8wh.png

There are two things that need to happen when a person clicks on the favorite button.

* The button needs to change state to purple
* An AJAX call needs to be made register the state change

The visual state change is as simple as adding a class to the element. Very little code is required for that. The ajax operation on the other hand is going to require a lot more code. So, if you were going to use the Queue handler you are going to register an action that can be handled. In the interim you can change the state, so users will get immediate feedback. Once the module has loaded to you can then also fire off the ajax operation. All of this is take care of in this code.

https://gist.github.com/1394631

So, the register function only handles potential actions, and not actions that have actually been triggered. That is what the queue_click function is for.

The queue_click can be called when an actual event has happened. In the case of the fav button, this will be a click event.

Now, this is where things get awesome. I am a fan of killing sacred cows. One of those in the front-end community is to not use onclick attributes, its certainly become dogma for many. Clearly we can see flickr doesn't care. I don't know the details of why flickr is using onclick, but I have to assume its because it is the lowest common denominator, and it works.

So, if we look at the the HTML of the favorite button. You can see that the queue_click is just called from the onclick handler. In turn the function will return false if the page is still waiting for code to load, thus canceling the browsers default operation.

https://gist.github.com/1394649

And, that's it. In this manner Flickr is able to handle all of us who are able to click faster then javascript is able to load. After breaking this technique down I wondered if there might be an easier way to handle actions before they loaded.