views:

2603

answers:

8

I've been struggling lately with understanding the best way to organize jQuery code. I asked another question earlier and I don't think I was specific enough (found in this question here).

My problem is that the richer you make an application, the quicker your client side gets out of control. Consider this situation...

//Let's start some jQuery
$(function() {        
    var container = $("#inputContainer");

    //Okay let's list text fields that can be updated
    for(var i=0; i < 5; i++) {

        //okay let's add an event for when a field changes
        $("<input/>").change(function() {

            //okay something changed, let's update the server
            $.ajax({
                success:function(data) {

                    //Okay - no problem from the server... let's update
                    //the bindings on our input fields
                    $.each(container.children(), function(j,w) {

                        //YIKES!! We're deep in here now!!
                        $(w).unbind().change(function() {

                            //Then insanity starts...

                        }); // end some function

                    }); //end some loop

                } // what was this again?

            }); //ending something... not sure anymore

        }).appendTo(container); //input added to the page... logic WAY split apart

    }; //the first loop - whew! almost out!

});  //The start of the code!!

Now this situation isn't too far from impossible. I'm not saying this is the right way to do it, but it's not uncommon to find yourself several levels down into a jQuery command and starting to wonder how much more logic can add before the screen begins to melt.

My question is how are people managing this or organizing to limit the complexity of their code?

I listed how I'm doing it in my other post...

+1  A: 

Stick some of the anon functions into global scope functions (or your own "namespace" object), especially the re-used functions, and it begins to look less like what you posted. Kind of like what you linked to.

Josh
+4  A: 

Well, for one, having a good IDE that understands javascript can help tremendously, even if just to identify matching demarcations (braces, parens, etc).

If your code starts to really get that complex, consider making your own static object to organize the mess - you don't have to work so hard to keep everything anonymous.

var aCustomObject = {
    container: $("#inputContainer"),
    initialize: function()
    {
     for(var i=0; i < 5; i++)
     {
      $("<input/>").changed( aCustomObject.changeHandler );
     }
    },
    changeHandler: function( event )
    {
     $.ajax( {success: aCustomObject.ajaxSuccessHandler} );
    },
    ajaxSuccessHandler: function( data )
    {
     $.each( aCustomObject.container.children(), aCustomObject.updateBindings )
    },
    updateBindings: function( j, w )
    {
     $(w).unbind().changed( function(){} );
    }
}
aCustomObject.initialize();
Peter Bailey
I want to vote you up for mentioning the benefit of a good IDE - but I want to vote you down for suggesting using Objects for code organization as opposed to their intended function.
matt lohkamp
on the other hand, maybe you don't mean to use Objects as organizational elements to the exclusion of other considerations, so I'll give you the benefit of the doubt.
matt lohkamp
The purpose of the object is not necessarily for organization, although that's a nice ancillary benefit, but to keep the global namespace consumption as small as possible. I don't think that's against their "intended purpose" at all. That type of thinking is desperately limiting.
Peter Bailey
+15  A: 

So far, I do it like this:

// initial description of this code block
$(function() {        
    var container = $("#inputContainer");

    for(var i=0; i < 5; i++) {
        $("<input/>").changed(inputChanged).appendTo(container);
    }; 

    function inputChanged() {
        $.ajax({
            success: inputChanged_onSuccess
        });
     } 

     function inputChanged_onSuccess(data) {
        $.each(container.children(), function(j,w) {
          $(w).unbind().changed(function() {
             //replace the insanity with another refactored function
          });
        });
      }
});

In JavaScript, functions are first-class objects and can thus be used as variables.

David Alpert
I like this approach too - keeps everything private. Unless you want some of the methods to be public;)
Peter Bailey
agreed; this approach doesn't leave behind any cruft in the global namespace as it encapsulates everything inside an anonymous closure. jQuery's functional style tends towards that pattern. Crockford's OOP pattern in BaileyP's answer is useful when you need a reference to your code block later.
David Alpert
+4  A: 

In my opinion the method described by BaileyP is what I use to start off with then I normally abstract everything into more re-usable chunks, especially when some functionality expands to the point where it's easier to abstract it into a plugin then have it specific to one site.

As long as you keep the large blocks of code in a seperate file and coded nicely you can then end up with some really clean syntax.

// Page specific code
jQuery(function() {
    for(var i = 0; i < 5; i++) {
         $("<input/>").bindWithServer("#inputContainer");
    }
});

// Nicely abstracted code
jQuery.fn.bindWithServer = function(container) {
     this.change(function() {
             jQuery.ajax({
                 url: 'http://example.com/',
                 success: function() { jQuery(container).unbindChildren(); }
             });
     });
}
jQuery.fn.unbindChildren = function() {
    this.children().each(function() {
        jQuery(this).unbind().change(function() {});
    });
}
+27  A: 

Just want to add to what was mentioned previously that this:

$.each(container.children(), function(j,w) {
    $(w).unbind().change(function() { ... });
});

can be optimized to:

container.children().unbind().change(function() { ... });

It's all about chaining, a great way to simplify your code.

John Resig
Ooo! The man himself responded! Sweet!
Hugoware
And reading your code is even more interesting - I didn't realize that you didn't need to iterate through each item... very cool
Hugoware
pfft, what would YOU know, john.
nickf
What does 'optimized' mean here? The code runs faster or a long piece code can be shortened? I think it's the latter, but I thought I asked to be sure.
Khnle
@Khnle: I take it to be: simpler, shorter code, easier to read. Unlikely to make much difference to execution time.
thomasrutter
+1  A: 

I described my approach in your other post. Short form:

  • do not mix javascript and HTML
  • use classes (basically start to see your application as a collection of widgets)
  • only have a single $(document).ready(...) block
  • send jQuery instances into your classes (instead of using plugins)
Jason Moore
A: 

Somebody wrote a post on the similar topic.

jQuery Code Does not have to be Ugly

HTH,

Irfan
+1  A: 

Use http://coffeescript.com/ ;)

$ ->
  container = $ '#inputContainer'
  for i in [0...5]
    $('<input/>').change ->
      $.ajax success: (data) ->
        for w in container.children()
          $(w).unbind().change ->
            alert 'duh'
Aldo Bucchi
Don't really understand how this will help the OP. But +1 anyway for showing me something new and interesting.
Robert Harvey