Question

Superfish JS is here.

Here’s the relevant code:

$.fn.extend({
    hideSuperfishUl : function() {
        // ...code here...
        return this;
    },
    showSuperfishUl : function(){
        // ...code here...
        return this;
    }
});

Questions:

Does $.fn.extend({...}); allow users to override hideSuperfishUl & showSuperfishUl functions? If so, what does the syntax look like to change these methods when calling the plugin:

<script> 

    $(document).ready(function() { 
        $('ul.sf-menu').superfish(); // How to override hideSuperfishUl &/or showSuperfishUl?
    }); 

</script>

Superfish was written a while back… Is this still the best way to allow users to override plugin functionality functions/methods/other? If not, is there a “best” way?

Answer 1

Going to try to answer my own question here… Please correct me if anything I write below is wrong! 😉

---

This article says this:

Extend

In my opinion, this is the least idiomatic way to create a jQuery
plugin. It uses the jQuery.fn.extend method instead of
jQuery.fn.pluginName:

(function($){
  $.fn.extend({
      myPlugin: function() {
          return this.each(function(){
              // do something
          });
      },
      myOtherPlugin: function() {
          return this.each(function() {
              // do something
          });
      }
  });
})(jQuery);

You will find this structure helpful if you need to add a large number
of plugin methods to jQuery. I would contend, however, that if your
plugin needs to add that many methods, there may be a better way to
structure its implementation.

I feel the extend method is used more by programmers transitioning
from other JS libraries. I personally find the simple $.fn.pluginName
= structure to be easier to read, and more in line with what you will normally see in jQuery plugins.

The Superfish JS is using the same code found in the above quote; long story short, showSuperfishUl() and hideSuperfishUl() are additional plugins in the jQuery $.fn namespace.

I was able to override said functions like so:

jQuery(function(){

    $.fn.showSuperfishUl = function() {
        console.log('OMG');
        return this;
    };

    $.fn.hideSuperfishUl = function() {
        console.log('BECKY');
        return this;
    };

    jQuery('ul.sf-menu').superfish();
});

Next, this article says:

Provide public access to secondary functions as applicable

// plugin definition
$.fn.hilight = function(options) {
  // iterate and reformat each matched element
  return this.each(function() {
      var $this = $(this);
      // ...
      var markup = $this.html();
      // call our format function
      markup = $.fn.hilight.format(markup);
      $this.html(markup);
  });
};
// define our format function
$.fn.hilight.format = function(txt) {
  return '<strong>' + txt + '</strong>';
};

We could have just as easily supported another property on the options
object that allowed a callback function to be provided to override the
default formatting. That’s another excellent way to support
customization of your plugin. The technique shown here takes this a
step further by actually exposing the format function so that it can
be redefined. With this technique it would be possible for others to
ship their own custom overrides of your plugin נin other words, it
means others can write plugins for your plugin.

Conclusion:

Both $.fn.extend and $.fn.pluginName.function are similar and allow the end user to easily override functionality; the former adds new plugins to the jQuery $.fn namespace, whereas the latter are functions which are contained within a single $.fn.pluginName namespace.

Summary and Best Practices says:

Don’t clutter the jQuery.fn object with more than one namespace per
plugin.

… therefore, my pick for “best” technique is $.fn.pluginName.function.