From time to time on this blog, we invite our developers to share on subjects that are near and dear to their hearts. This post about best practices for referencing external JavaScript libraries in Visualforce originally appeared on March 29, 2013 on Zach's First Fruits blog. This is the method we use ourselves to reference external JS libraries while building Skuid.
Let's pool our thoughts: best practices for Salesforce ISV/OEM app development.
To help foster an ongoing conversation among Salesforce ISV and OEM partners (aka developers of Salesforce AppExchange apps) I started this discussion on the Salesforce ISV Partners LinkedIn group, which I encourage fellow ISV's/OEM's to join.
One of the best practices I brought up was the need to properly "protect" or "sandbox" your application's references to external JavaScript libraries within complex "mash-up" pages that include JavaScript code written by various other ISV's/OEMs/consultants/developers, as well as underlying salesforce.com JavaScript code.
These days, more and more apps being developed on the Salesforce Platform rely heavily on external JavaScript libraries such as jQuery, jQuery UI, jQuery Mobile, ExtJS, Sencha Touch, KnockoutJS, AngularJS, Backbone, MustacheJS, Underscore, JSONSelect, etc.
Leveraging these libraries is definitely a best practice, don't reinvent the wheel! As jQuery quips, "write less, do more!" As a Salesforce consultant, I think, this is generally the goal :).
Problems emerge, though when multiple ISVs include different versions of these JavaScript libraries as Global Variables within their Visualforce Pages or Visualforce Components, because whichever version is loaded last will, by default, overwrite the earlier version.
This makes it very difficult to mash-up/integrate Visualforce Components or Pages from multiple ISVs into a single page. When faced with this, a common developer response is to stop using the latest version of the external library and trying to make their code work against the earlier version of the library forcibly included in the page (perhaps by a managed Visualforce Component or embedded Visualforce Page). Fortunately, there is a better way to avoid this.
In a nutshell, the solution is: "protect" or "localize" your references to any external libraries, ideally in a JavaScript namespace corresponding to your managed package.
For instance, if your Salesforce Platform application has the namespace "skuid", you're already going to probably have various JS Remoting functions available within the "skuid" JavaScript object that Salesforce automatically creates in pages with controllers with JS Remoting methods, and as an ISV, you are ensured of your managed app's namespace being Salesforce-unique.
So this namespace is just about the safest global variable you can use in the Salesforce world (anyone else who messes with it is being very, very naughty).
As a brief side-note, here's how to ensure that your app's "namespace global" has been defined before using it:
To protect your external library references, store a unique reference to these libraries within your namespace's object, e.g. immediately after loading in an external library, such as MustacheJS,
Then, even if some other VF Component or Page loads in a different version of this library later on, you will still have access to the version you loaded (0.7.2)
