Grow your CSS skills. Land your dream job.

Cache Your jQuery objects In a jQuery object itself

  • # August 3, 2012 at 5:28 pm

    I just had an interesting thought that I’d never seen published anywhere yet about jQuery. It’s real simple, nothing new, but I’d never thought about it before.

    Normally, I’d do something like this:

    var menu    = $('.main-menu'),
    items = menu.find('li'),
    anchors = menu.find('a');

    But down the line in my code, using items loses its connection with menu. I mean sure, I could have used variables like ‘menuItems’ and ‘menuAnchors’, but why do that when you could just do:

    var menu = $('.main-menu');

    menu.items = menu.find('li');
    menu.anchors = menu.find('a');

    // Later
    menu.anchors.on('click', function() {}); // etc...

    Of course you’re limited to using variable names that aren’t already in use by javascript and jQuery, but its convenience is nice to logically group objects together like that.

    I mean, you could do the same with creating an empty object first, then storing the jQuery objects inside that, but it’s just one unnecessary step when you already have a perfectly good object to work with.

    Just thought I’d share my “discovery” today, haha.

    # August 4, 2012 at 2:06 am

    It’s a very messy way of working on things and you’re also giving some of your control away. You should be working within your own objects and your own namespace, not jQuery’s. You may be creating memory leaks all over the place, but you wouldn’t know since you (I’m assuming here) don’t actually know what jQuery is doing.

    It does look pretty nice though, but I pretty much do something similar anyway.:

    var menu = $('.main-menu');

    menuItems = menu.find('li');
    menuAnchors = menu.find('a');

    // Later
    menuAnchors.on('click', function() {}); // etc...

    Or you could do this:

    var menu = $('.main-menu');

    menu_items = menu.find('li');
    menu_anchors = menu.find('a');

    // Later
    menu_anchors.on('click', function() {}); // etc...
    # August 4, 2012 at 4:12 pm

    I just have some questions, if you wouldn’t mind explaining further. Thanks.

    “It’s a very messy way of working on things and you’re also giving some of your control away.”
    How so?

    “You should be working within your own objects and your own namespace, not jQuery’s.”
    Why?

    “You may be creating memory leaks all over the place, but you wouldn’t know since you (I’m assuming here) don’t actually know what jQuery is doing.”
    Do YOU know what it is doing?

    # August 5, 2012 at 11:22 am

    Are you really trying to learn here or are you set on your way being “right”? I’m asking because the third quote there I begin with “You may” which actually answers your question, but cache your jQuery objects within jQuery objects if you want, I’m really not going to stop you – All I’m saying is that it’s a bad idea since you don’t control jQuery.

    As for modular code and namespaces:
    For small js scripts I guess it’s fine to work in jQuery’s namespace but once you start working on larger apps it becomes a problem and your own namespace becomes necessary. By default backboneboilerplate comes with all of this. It sets up modules for you and links all your scripts together with require.js.

    # September 20, 2012 at 2:40 am

    I think you both made valid points. I don’t feel safe adding my properties and methods to an object created by another library, so i store jQuery elements like so:

    var menu = {
    $: $(‘#menu’),
    prop: value
    };

    menu.$.addClass(‘super-special’);

    Interestingly enough though I saw memory leaks mentioned somewhere and a quest to learn more lead me here. I’m fairly certain that none of the code above would cause memory leaks my my definition (a memory leak keeps growing IMO, not simple be maintained across the life of a page) some articles though, stated storing DOM objects to variables inside closers = the most common cause for leaks.

Viewing 5 posts - 1 through 5 (of 5 total)

You must be logged in to reply to this topic.

*May or may not contain any actual "CSS" or "Tricks".