Patterns // Article Listing

Articles in the Patterns category cover industry best practices and repeatable conventions you can use to produce clean, effective jQuery code. Patterns can be as small as a few lines or as large as the structure of an entire application as long as the pattern can be continually repeated with effectiveness.

How Good C# Habits can Encourage Bad JavaScript Habits:
Part 3 – Function Scope, Hoisting, & Closures

Published on Thu, October 21, 2010 in Multipart Series, Patterns

This is the third post in a multi-part series covering common mistakes C# developers tend to make when they first start writing JavaScript.

The first post covered the following topics:

  • 1. Having Variables & Functions in Global Scope
  • 2. Not Declaring Arrays & Objects Correctly

The second post covered the following topics:

  • 3. Not Understanding False-y Values
  • 4. Not Testing & Setting Default Values Correctly
  • 5. Using the Wrong Comparison Operators
  • 6. Not Using the for…in Statement Correctly

Introduction

This post continues to focus on areas where C# developers tend to make bad JavaScript decisions based on their previous training. The languages are similar enough syntactically that C# developers tend to not invest the time to learn JavaScript’s differences.

The following post points out several misunderstandings that can get you into some confusing situations.

How Good C# Habits can Encourage Bad JavaScript Habits:
Part 2 – False-y, Testing and Default Values, Comparisons, and Looping

Published on Wed, October 13, 2010 in Multipart Series, Patterns

This is the second post in a multi-part series covering common mistakes C# developers tend to make when they first start writing JavaScript.

The first post covered the following topics:

  • 1. Having Variables & Functions in Global Scope
  • 2. Not Declaring Arrays & Objects Correctly

Introduction

This post continues to focus on areas where C# developers tend to make poor decisions when writing JavaScript based on their previous training. The languages are syntactically similar enough that C# developers tend to not invest the time to learn JavaScript’s differences.

The following post points out several misunderstandings that can get you into some confusing situations.

How Good C# Habits can Encourage Bad JavaScript Habits:
Part 1

Published on Thu, October 7, 2010 in Multipart Series, Patterns
This is the first post in a multi-part series covering common mistakes C# developers tend to make when they first start writing JavaScript.

Introduction

Many people come to jQuery and believe that their knowledge of a previous classical language (C#, Java, etc) will help them be successful at client-side scripting. You can use your classical language skills to accomplish a large amount of functionality with jQuery. However, the more client-side code you write you will find yourself uncovering strange bugs because you didn’t take adequate time to learn JavaScript properly.

“…it turns out that if you have absolutely no idea what you’re doing in the language you can still generally make things work.” –Douglas Crockford, Yahoo!’s JavaScript Architect, Douglas on JavaScript -- Chapter 2: And Then There Was JavaScript

This article is targeted for developers that use jQuery but haven’t invested the time necessary to learn JavaScript. The intent is to help you avoid some common mistakes when moving from a classical language (Java, C#, etc) to JavaScript.

jQuery is a library that is written in JavaScript. It is important to remember that you will always be writing in JavaScript when using jQuery. It is inevitable that you will run into native JavaScript concepts that are foreign to the classical language proficient developer. Taking the time now to be proficient in JavaScript will increase your client-side code quality, efficiency, and decrease code maintenance.

Creating an Ajax Component:

Handling Errors and Loading Notifications with Publish and Subscribe

Published on Tue, September 28, 2010 in AJAX, Multipart Series, Patterns, Uncategorized
This is the second post in a multi-part series on creating a JavaScript component for handling your Ajax requests in front-end development across your enterprise. You can find the first post here:

In the last post we covered some introductory topics for creating your own JavaScript utility library, which wraps functionality for Ajax. We’ll start where we left off. Our first step will be to add a few tweaks to our library to make it more usable:

var mySiteAjax = ( function( $ ) {
  return (
     function( params ){
      var settings = $.extend({
        url: "", 
        spinner:  undefined, 
        dataType: "html",
        data: "",
        type: "GET",
        cache:  false,
        success:  function() { }
      }, params );

      $.ajax({
          beforeSend: function() { 
            $( settings.spinner ).show();
          },
          url: settings.url,
          dataType: settings.dataType,
          type: settings.type,
          data: setting.data,
          success: settings.success,
          complete: function() {
              $( settings.spinner ).hide();
            }      
        });
    } 
  );
})(jQuery);

We’ve done two things to our old example. We’ve added new parameters for type and data that could be passed in. Additionally, we’ve removed a named function and returned an object literal. This enables easier usage:

mySiteAjax({
  url: "myUrl",
  success: function( data ) {
    //do something with the data here
  }
});

Although a good start, this solution is not yet satisfactory as we are not yet handling errors in any capacity. How do we handle errors and display messages to the user? Additionally showing and hiding of loading notification images is present but not customizable. What if a page doesn’t want to do a simple showing and hiding of load images? How can we decouple the notifications from our Ajax component library?

Javascript Parameter Patterns with $.extend and Beyond

Published on Thu, August 12, 2010 in Patterns

Enterprise developers have a tendency to misunderstand JavaScript’s function parameters. When getting started, many expect JavaScript functions to work much like the server-side languages they’re already familiar with. There can then be a fair bit of confusion when they find out things work a little differently with JavaScript.

The languages generally used on the server-side of enterprise development have static typing. The number and type of each parameter must be declared. In contrast JavaScript is considered a language with dynamic typing. JavaScript parameters do not have to be tied to a specific type at compile time. Additionally server-side languages do not include any of the ‘free’ parameters we get in JavaScript (more discussion on these parameters below).

A great example of the gap between common server-side languages and JavaScript is the .each method. To use this method you supply a function which will be executed against each element within the jQuery wrapped collection.

My first encounter with .each was similar to this:

//...
// note: this example is archaic as of 1.4 release
// please use function callback with .text instead!
$('.someClass').each(function() {
  var $this = $(this);
  $this.text($this.text() + " some extra text");
});
//...
$('.someClass').each(function(idx,val) {
  if(!(idx % 3)) { //modulus : will be true
                        //on every third element
    $(val).somejQueryMethod();
  }
});
//...

JS Bin demo

Mock Your Ajax Requests with Mockjax for Rapid Development

Published on Thu, July 22, 2010 in AJAX, Patterns, Plugins

Most backend developers are familiar with the concepts of mocking objects or stubbing in methods for unit testing. For those not familiar with mocking, it’s the simulation of an interface or API for testing or integration development purposes. Mocking with front-end development though is still quite new.

Much of the development that appendTo does focuses on front-end development tied to RESTFUL web services. As such we’re able to spec out the service contract and data format at the beginning of a project and develop the front-end interface against mock data while the back end team builds the production services.

I originally developed this plugin for appendTo back in March of this year and our team has been using it in all of our projects since. appendTo is committed to sharing our tools and best practices with the community so it’s with much excitement that we’re releasing this plugin. (A sneak peek was available to the Silicon Valley JavaScript Users Group and those that attended our OSCON tutorial)

Plugin Overview

Abstract: The mockjax plugin is a development and testing tool for intercepting and simulating ajax requests made with jQuery with a minimal impact on changes to production code.

Enterprise AJAX Patterns Part 1:
From Enterprise Beginnings

Published on Sat, July 17, 2010 in AJAX, Multipart Series, Patterns

jQuery Ajax features provide a slick way to make asynchronous javascript calls from any browser. jQuery even gives us helpers methods to make the calls even simpler. $.get, $.getJSON, $.getScript, $.load, and $.post all give great ways to set up default features and get your ajax calls done quickly. We often see enterprise developers taking advantage of these shortcut methods for basic Ajax needs.

However, enterprises today require scalable solutions that gracefully handle errors, messages to the user, spinners, and other aspects of a rich user experience. In these series of posts we are going to step beyond the basic Ajax functionality and build a scalable library solution. In order to create a functional library you’ll need to understand the .ajax method and the parameters allowed. If you don’t already have a handle on .ajax, please visit the extremely useful api site for a quick primer.

For the purpose of these posts we are going to start with a pattern that is often seen in enterprise situations for ajax calls. In the below example we will attempt to retrieve data from the server with a GET http action via the jQuery.ajax method.