JAVA SCRIPT - Using an External Library: Building on the jQuery Framework

Using an External Library: Building on the jQuery Framework 


Problem

You want to create application-specific libraries without having to create your own li‐ brary of reusable routines.

Solution

Use one of the JavaScript libraries, such as jQuery or Underscore, to provide the basic functionality you need, but isolate the use so that you can swap libraries if needed.

EXPLAIN

There are good reasons for using an existing JavaScript library such as jQuery. One is that the code has been robustly tested by several people. Another is that you can tap into a community of support when you run into problems in your applications. jQuery is also extensible, with a wealth of plugins you can incorporate, as well as the ability to create your own. 

Then there’s the time-saving aspect, as jQuery takes over managing the tedious bits of your application. I’m focusing primarily on jQuery because it is the library incorporated into most of the applications I use. It’s also small, specific, modular, and uncomplicated. 

However, there are other good general-purpose and extensible libraries, depending on your needs and preferences.

To use jQuery, include a link to the library before providing links to your own or other, secondary libraries. If using the CDN, use the following:


<script src="//code.jquery.com/jquery-2.1.1.min.js"></script>
A basic starting page that jQuery provides is the following, where the jQuery script is
downloaded, and included in the web page’s body:
<!doctype html>
<html>
<head>
 <meta charset="utf-8" />
 <title>Demo</title>
</head>
<body>
 <script src="jquery.js"></script>
 <script>
 // Your code goes here.
 </script>
</body>
</html>


If you are placing the scripting block in the body, consider putting it at the end, making it easier to discover. There are several application-specific libraries that are dependent on jQuery, so you may want to check if they provide it as part of their own installation.

One aspect of jQuery that differs from most of the examples in this book is that jQuery’s starting point for script is not window.onload, as used for many applications. Instead, the jQuery library provides a page start routine that waits for DOM elements to be loaded, but does not wait for images or other media to finish loading. This beginning point is called the ready event, and looks like the following:

$(document).ready(function() {
...
});

The code snippet demonstrates a couple of other things about jQuery. First, notice the dollar sign element reference: $(document). In jQuery, the dollar sign ($) is a reference to the main jQuery class, and acts as a selector for all element access in the application. If you’re working with jQuery, use the jQuery selector rather than your own element access, because the jQuery selector comes with prepackaged functionality essential for jQuery to operate successfully.

The syntax you use when querying for page elements is the same as the syntax for the querySelector() and querySelectorAll() methods, described in Chapter 5. It’s based on CSS selector syntax for accessing a named element, such as the following:

#divOne{
 color: red;
}

Using jQuery to access a div element with an id of divOne looks like this:

$undefined"#divOne").clickundefinedfunctionundefined) {
 console.logundefined"element clicked");
});

This code snippet returns a reference to the div element identified by divOne, and then attaches a function to the element’s onclick event handler that prints out a message. The code also demonstrates another fundamental aspect of jQuery—it makes heavy use of method chaining. Method chaining is a way of appending methods one to another. In the code, instead of returning a reference to the div element and then attaching the event handler function to it, you attach the event handler directly to the element request.

There is extensive documentation and tutorials on using jQuery, so I’ll leave any further exploration of jQuery for an off-book exercise. However, I did want to cover one im‐ portant aspect of using jQuery—or any framework library with your own applications. The key to making these work now and in the future is to wrap the library use in such a way that you can swap one library out for another, without having to recode your applications—or, at least, minimize the amount of recoding you would have to do. Instead of using the jQuery ready event, create your own so you don’t build a higherlevel dependency on jQuery.

Instead of using jQuery methods directly in your business logic, use your own objects and methods, and call the jQuery methods within these. By providing a layer of abstraction between the implementation of your application’s busi‐ ness logic and the external framework library, if someday you stumble upon Frew, the Wonder Library,

you can swap out jQuery (or another library or framework) and build on Frew. When I wrote the first edition of the JavaScript Cookbook, the big libraries at the time were Prototype.JS and jQuery. Since then, Prototype.JS hasn’t been updated since 2012. This is why you want to isolate which library you use: if it’s no longer being supported, you can swap to another if necessary. It may seem like jQuery will be around forever, but things change.

Of course, some frameworks really do require a commitment, so if you go with this approach, make sure that your choice has an active community and lively support.

0 comments:

Post a Comment