×
  • Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
 

How To Manage Large jQuery Apps

by Front-End Web Developer at Quotient Solutions, Inc on Apr 24, 2010

  • 29,260 views

Get off the DOM and check out a few ways of writing jQuery applications that stand up to a full development cycle. jQuery's API is fantastic, but hinging your entire large application on that API can ...

Get off the DOM and check out a few ways of writing jQuery applications that stand up to a full development cycle. jQuery's API is fantastic, but hinging your entire large application on that API can be more harmful than helpful. Instead, learn how to use the features in jQuery and vanilla javascript to build an application structure that is both modular and manageable. A lot of features you already know and love, plus a little object-oriented JavaScript, can go a long way in making your JavaScript maintainable.

Statistics

Views

Total Views
29,260
Views on SlideShare
26,465
Embed Views
2,795

Actions

Likes
93
Downloads
738
Comments
13

23 Embeds 2,795

http://blog.mklog.fr 1386
http://speakerrate.com 880
http://www.dooriented.com 332
http://www.slideshare.net 113
http://onwebdev.blogspot.com 25
http://localhost 18
http://www.linkedin.com 8
http://webcache.googleusercontent.com 8
http://192.168.6.52 3
https://www.linkedin.com 3
http://translate.googleusercontent.com 3
http://static.slidesharecdn.com 2
http://us-w1.rockmelt.com 2
https://twitter.com 2
http://feeds.feedburner.com 2
https://cloudup.com 1
http://onwebdev.blogspot.com.es 1
http://pinterest.com 1
http://blog.gabrieleromanato.com 1
http://migueldev.com 1
http://paper.li 1
http://localhost:3000 1
http://apache-wicket.1842946.n4.nabble.com 1
More...

Accessibility

Categories

Upload Details

Uploaded via SlideShare as Apple Keynote

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel

110 of 13 previous next Post a comment

  • ansolas An Solas, AnSolas at Spiritual Healing Festival Hello,
    u suggest loading js modules something like this:
    var test = Object.create(myPlugin);
    test.init({color:'#101CA7'});
    test.doit('hello');

    how would you load ready jQuery Plugins such as $('#carousel').rcarousel ?
    1 year ago
    Are you sure you want to
    Your message goes here
    Processing…
  • zoghal Saleh Souzanchi, برنامه نویس وب at Irsa Web very good 2 years ago
    Are you sure you want to
    Your message goes here
    Processing…
  • cifroes cifroes Tried to download this and its in .key format? what kind of program reads that? would be nice to be in pdf :) 3 years ago
    Are you sure you want to
    Your message goes here
    Processing…
  • SlexAxton Alex Sexton, Front-End Web Developer at Quotient Solutions, Inc Looks like you've found a good solution to your problem. It's true, jQuery's terse awesomeness tends to get in the way of some of the scalable patterns, and there's not a ton of super-pretty solutions.

    Your solution looked fine, but you may have also been able to get around the problem with the $.proxy method that was introduced in jQuery 1.4 - it will let you change the context of your handlers back to what you want. It may be an uglier move though, as there's a lot of wrapping functions involved.
    3 years ago
    Are you sure you want to
    Your message goes here
    Processing…
  • bradleymann Brad Mann, Software Engineer at MarkLogic Ended up figuring it out. In the inheritedFacet code, we have a create method that is called when the widget is created. We attach live events to the elements in the widgets (checkboxes, radios) in the create event. The key is to forward along the context using the eventData parameter of live. Something like this:

    var inheritedFacet = $.extend(true, {}, baseFacet, {
    options: {
    //Here is an extra option in the subclass, for good measure
    option3: ’rules!’
    },
    create: function() {
    $().live('click', {self: this}, this.onClick);
    },
    onClick: function(evt) {
    var self = evt.data.self; //ZOMG! Now we've got the object's context
    alert(self.options.option1); //Use self to access the object
    }
    });

    jQuery FTMFW :-)
    3 years ago
    Are you sure you want to
    Your message goes here
    Processing…
  • bradleymann Brad Mann, Software Engineer at MarkLogic Alex,


    Awesome deck, I literally lol’d. I’m working on a project and trying to implement the prototypal inheritance model (wanna make papa crock proud), and I’m running into an issue I’m trying to work around. I’m using jQuery UI and attempting to create a search faceting hierarchy. I create a baseFacet like so:


    var baseFacet = {

    doSomething: function() {

    alert(’coolness’);

    },

    options: {

    //These are the default options you get with the base facet

    option1: ’papa’,

    option2: ’crock’

    }

    };



    var inheritedFacet = $.extend(true, {}, baseFacet, {

    options: {

    //Here is an extra option in the subclass, for good measure

    option3: ’rules!’

    },

    onClick: function(evt) {

    //This line doesn’t work...how can I access the members of this object from this event handler?

    alert(this.options.option1);

    }

    });



    var myCoolNewWidget = object.Create(inheritedFacet);

    $.widget(’omg.checkoutthiswidget’, myCoolNewWidget);

    $(’.widgetme’).checkoutthiswidget({option1: ’john’, option2: ’resig’});



    The problem is: when I execute checkoutthiswidget on my dom object, and the click event is fired, ’this’ in my onClick handler is conveniently (and frustratingly) overridden to be the dom object that fired the event. Have I lost the ability to access my widget class at this point? Is there a convenient way/best practice for accessing the members of the object from within event handlers?



    Thanks so much,

    Brad
    3 years ago
    Are you sure you want to
    Your message goes here
    Processing…
  • SirWay Alexander Vey, Web Developer at Everywhere There you go Alex. I see you've understand what I've tried to show you. Your solution with
    $.extend(this, {'options' : options});
    it's kind of interesting, I've never thought of that solution but I like it and yes, it's work gracefully.

    It was a pleasure for me to discuss with you about that 'problem' and I wanne thank you for your time and commitment. Keep up the good work!
    3 years ago
    Are you sure you want to
    Your message goes here
    Processing…
  • SlexAxton Alex Sexton, Front-End Web Developer at Quotient Solutions, Inc @Alexander Thanks so much for pointing this out.

    I think it was clear where my line of thinking was. You are definitely correct, that my way breaks. However, all of my reasoning seemed very correct to me, so I traced down where the source of the problem was.

    When I do an object.create() - it creates a new element with the properties of the first, all stored on the new object's prototype.

    If I were to modify/redefine one of the new object's properties, it would not destroy the original object, it would just add the definition as an ownProperty.

    --- this is where it get's tricky ---

    `this.options` on my new object instance referenced the prototype of the 'this' object, which is just a link to the ownProperties of my original function.

    If I were to set this.options to something else, it would create a new copy of this.options on my instance of the object. BUT that's not what I did.

    $.extend simply modifies the object. I was well aware of this, but I thought that, if I modified the 'this.options' object it would create a new instance and place it as an ownProperty. This is not true. So it ends up overwriting the default settings each time because the Object.create stores a reference via it's prototype to the original options, and then when you _directly_ extend the options variable on the instance, it actually extends the prototype, and doesn't create a new instance.

    Your solution works just fine, but I was actually trying to show that passing an empty object to the beginning of $.extend isn't always necessary or recommended. I still think that's true. I don't like using that as a general rule since it often blows away a lot of differential inheritance.

    So I would suggest, as a solution:

    instead of

    this.options = $.extend({}, this.options, options); // which works

    do

    $.extend(this, {'options' : options});

    THAT, I'm pretty sure, would work. ( demo here: http://alexsexton.com/objecttest/ )
    3 years ago
    Are you sure you want to
    Your message goes here
    Processing…
  • SirWay Alexander Vey, Web Developer at Everywhere @Alex

    Thank you for your answer of my comment. I think you didn't exactly get the point of my objection.
    For better understanding and explaining myself I've created a new example (somehow my first example at jsbin.com isn't working?!)
    You can find my new 'testcase' at:

    http://avey.de/public/development/js/extend-options.htm

    I've extended your example by using all one of the three possible routines for each example.
    You will see that only the 3rd instance works correctly. The first box will become red, the second one blue. The other both instantiations show that the name of the hover class in the options will be overridden by the seconde plugin init call.

    I hope that example shows what I try to explained you at my first comment.

    Anyway I have to thank you not only for taking time to create this slide but paying attention of people like me who just wanne give you feedback.
    3 years ago
    Are you sure you want to
    Your message goes here
    Processing…
  • SlexAxton Alex Sexton, Front-End Web Developer at Quotient Solutions, Inc @alexander

    Normally, I think you'd be right, and perhaps I'm still missing something, but I think the example is ok.

    Two things:

    In the plugin code, there's this line:

    Object.create(hoverClass)

    This creates a new instance (a new context for 'this').

    When the override happens, it overrides just the options of that instance. I actually made it redundant for clarity, but the line could actually just be:

    $.extend(this.options. options);

    instead of:

    this.options = $.extend(this.options. options);

    2) Even if you are right, I think the problem would still exist, since you're assigning the result of your $.extend call to the 'this.options' variable anyways.

    These three line's end in the same object state

    $.extend(this.options, options);
    this.options = $.extend(this.options, options);
    this.options = $.extend({}, this.options, options);

    If I had the options outside of the individual instance of the object (perhaps just in a variable above the object), or I called the extend before I created a new instance, I think you'd be right, but in this case, I think my code should work. Do you have an example otherwise?

    Either way, thanks a ton for the feedback and actually taking the time to read through and correct things I may have done wrong. It means a lot to see people actually paying attention.
    3 years ago
    Are you sure you want to
    Your message goes here
    Processing…

110 of 13 previous next

Post Comment
Edit your comment

How To Manage Large jQuery Apps How To Manage Large jQuery Apps Presentation Transcript