Not really, but I do believe this to be a very important and extremely helpful one in the event that you are building web apps that intend to be loaded on 3rd party websites.
There are lots of different ways to build 3rd party web apps, ranging from custom JS implementations per user to a single API reference delineated by something like options. A lot of web apps use the iframe technique and do lots of browser hacks to get cross-communication to work, but I prefer JSONP.
By using JSONP, you reduce the chance for conflicts because nearly every browser in use (even IE6!) supports the protocol. In either scenario, your code needs to communicate back and forth with input from the user on the website. This is often done by building completely custom JS implementations for the JS API, which I always found to be a little frustrating. There are so many quirks to account for that you have to try and mitigate.
That’s when I had this “brilliant” idea:
What if I just used jQuery in my web app?
The jQuery team has done a ton of work to normalize JS behavior across browsers, and provides a rich and easy-to-use API for doing common things. I love jQuery, so I set out on a quest to figure out how to do this reliably. The fruits of my labor are below.
The 3rd Party JS Init Code
Let’s assume that your code snippet for your webapp references a file called app.js. Let’s build out an example snippet of what a client would receive for your web app.
This is nothing crazy. We create a div that will hold whatever we want to load into the page from our app, create a global variable to hold some options and then pass those options into our app object. The code checks for HTTPS and fires once the script is fully loaded into the page.
The 3rd Party JS File
You noticed in the init code above that we created a new instance of My_App, our JS object that is going to house everything we do, including loading and utilizing jQuery.
In our myapp.js file, we create our object, My_App, and then denote a couple of properties, foo, bar and jQuery. foo and bar aren’t necessary – it’s just to give you an idea of what you might see or use.
From here, the init method is what fires our JS API. We check to see if any params have been passed in and add them as object properties. Finally, we get to the meat of the tutorial – getting jQuery inside of our app.
There are a few things we need to consider:
How do I load jQuery on the page?
What is the page already has jQuery loaded on it?
Can I use the pages’ original copy of jQuery if it exists?
What about dependencies?
These are all great questions, and I will address each of these below.
Loading jQuery if it does not exist
Before we attempt to do anything fancy, we need to check and see if jQuery exists on the page or not. We can do that by checking to see if jQuery is a property of the global window object. If its undefined, we can load it in.
If jQuery does not exist, we are going to load it in from Google (since Google’s CDN is super fast) asynchronously. (As an aside, all of this is asynchronous (for real), so it doesn’t impact page load times.) We will use the same method as in our init code to check and see when it is fully loaded into the DOM, and when it is, we will fire off a handler that will allow us access to the jQuery object inside of our app.
In the load handler method, the function takes one parameter, exists. This is simply a flag to determine whether or not jQuery already exists on the page so that we can mitigate potential conflicts.
Loading jQuery if it already exists but isn’t the right version
A lot of websites use jQuery, so there is a very real possibility that your user has already loaded jQuery on their page. In that case, we want to check and make sure that the version loaded into the window is the version we need. If it doesn’t match the version we want, we need to load jQuery in, and this time, we set the exists flag to true since jQuery already exists on the page.
Loading jQuery if it already exists and is the right version
This is the best case scenario. Since jQuery is already loaded and it is the correct version, we can just make use of that object instead. Piece of cake, so here is the code we have so far.
So before we move forward, we need to mitigate potential jQuery version conflicts and store the global jQuery object locally so that we can use it inside of our app.
In order to handle version conflicts, the code in the loadjQueryHandler method looks like so:
If jQuery already exists, we can use window.jQuery.noConflict = true to handle versions. This will reset the original jQuery window object to its correct version and properties and set the new jQuery object to our custom localized copy. Pretty sweet, right?
If jQuery doesn’t exist, we will just go ahead and set the global jQuery object itself and then store that in our custom property.
Loading the App
Finally, we load our app. This is the easiest part of all.
Finally, we have access to jQuery! We can now use jQuery in our app to do anything from fadeIn elements to make JSONP requests to do all other sorts of cool stuff. Here is all the code encapsulated into one code block.
Hope you enjoyed the tutorial! Take the headache out of building your own custom JS solutions and let the tried-and-true tested framework named jQuery do all of the hard work for you.
I live and breathe WordPress. I create products around WordPress (Soliloquy and OptinMonster), contribute to WordPress core and do lots of fun development around WordPress in general. You can find me on Twitter, Facebook and Google+.
I have created over 100 custom themes and plugins for clients of all shapes and sizes. I have also contributed to WordPress Core, spoken at several WordCamps and created some powerful WordPress products.
I create solutions that add value to your business.