Scope of $(this) in jQuery plugin

[DrQuincy]

I’m trying to understand the scope of $(this) in a jQuery plugin. Here’s a very simple plugin.

;(function($){

    $.fn.somePlugin = function(options) {  
    
        // Defaults
        var defaults = {  
        
            foo: 'bar'
        
        };
         
        // Options
        var options = $.extend(defaults, options);
        
        
        // Return each object
        return this.each(function() {

            // Cache $(this)
            var $this = $(this);
            
            
            // Do whatever the plugin needs to do here


            // A test public function
            $.fn.somePublicFunction = function() {
            
                // $this or $(this)?
            
            };
            
            // A test private function
            function privateFunction() {
            
                // $this or $(this)?
            
            }
        
        });
    
    };

})(jQuery);

When you loop through all of the matched elements (.each) I am caching $(this) to $this. When calling functions (per my two example functions) should you always use $(this) and not my cached $this? If so, is this because you will always end up working with the last matched element in the array?

I’ve always found the jQuery plugin structure a bit confusing!

[Paul_Wilkins]

@DrQuincy

When calling functions (per my two example functions) should you always use $(this) and not my cached $this?

In this case (haha, that’s enough), the cached value of $this refers the object that your plugin is attached to.

I tend to find that it’s better to use named variables instead, to help prevent confusion.

var cachedObject = $(this);

That way when you’re in the midst of some code, you have a fighting chance of figuring out just what on earth is going on.

$.fn.somePublicFunction = function() {
    var somePublicFunction = $(this);
    // Now instead of $this or $(this), you have cachedObject and somePublicFunction to work with.
};

[DrQuincy]

Sorry for the late reply. Thanks, I think I understand better now.

As a side question, I’ve seen public functions set a number of ways including:

$.fn.somePlugin = function(options) {

    $.fn.somePublicFunction = function() { };

}

As well as…

$.fn.somePlugin = function(options) {
        
};
    
$.fn.somePlugin.somePublicFunction = function() { };

I prefer the first way because you can use all the variables declared within the plugin. Are there any disadvantages to the first way?

[Paul_Wilkins]

@DrQuincy

I prefer the first way because you can use all the variables declared within the plugin. Are there any disadvantages to the first way?

About the only disadvantage that comes to mind with the first example is that it’s harder to split up the code to separate files when things grow too large.

jQuery is an excellent example of this. If you go to the jQuery github, you’ll see that they can develop each in separate files because they extend on to the main core. This also helps when it comes to packaging it all together, for the files can be all streamlined together into just the one scripting file that contains everything.

[DrQuincy]

Thanks, Paul. That’s good to know.