Mail Call : jQuery Custom Events

I got a lot of nice responses from my post here on a JavaScript skeleton. One person, though, wanted more...

Here's the pertinent part of the email:

"But you wrote some posts in the past about event-driven programming. I didn't see anything in your skeleton about that. Are you not using that any more?"

I'm using it, alright. In fact, I feel it's a bit of a secret weapon and I'm waiting for the day when event-driven programming gets "hot" and spoils it for me.

But for you, bubula, I'll explain why I use it and, in simplified form, how.

The Why. Before jQuery engulfed all of my development, I didn't really need event-driven programming. It was pretty simple: I made a request; I waited for a response. Then I repeated this cycle with something else.

That works when you work in a synchronous world -- one in which things happen one after another, in predictable order. All that goes out the window when you start working with Ajax.

Consider this code:

var customerCreated = false;
$.post(
   'Customer/create',
   {
      customer: 'Dietrich Fisher-Dieskau'
   },
   function( response ){
      if ( response.success ) {
         customerCreated = true;
      };
   },
   'json'
);
if ( customerCreated ){
   alert('We have a new customer!');
};

You see the problem? The jQuery.post bit sends a request off through the HTTPRequest thingie. Assuming things go well with the server, we'll get a response back, but it almost certainly will not happen before the conditional code that checks for a createdCustomer executes.

"But there's an easy solution for this!" you say. "Just move your alert into the $.post success function, like this:"

var customerCreated = false;
$.post(
   'Customer/create',
   {
      customer: 'Dietrich Fisher-Dieskau'
   },
   function( response ){
      if ( response.success ) {
         customerCreated = true;
         alert('We have a new customer!');
      };
   },
   'json'
);

Well, yes that will work, but do you see what we've done? We've caused the code responsible for creating a new customer to deal with the consequences of a new customer being created. And that is most definitely not a good thing. Let's say I have a tabbed interface. In Tab A, I have a list of customers. In Tab B, I have the code to create a new customer. Now, the code in Tab B needs to have Tab A's customer list update itself. There's a fancy programmer term for this bad thing: separation of concerns. As in "Tab B should worry about Tab B and never you mind about Tab A."

But, Tab A does, in fact, need to know if a customer has been added, right? It needs to refresh itself or, at the very least, let the user know that the current list is out of date.

That's just where events come in so handy.

Look at this reworked version of the code:

$.post(
   'Customer/create',
   {
      customer: 'Dietrich Fisher-Dieskau'
   },
   function( response ){
      if ( response.success ) {
         $( '#TabB' ).trigger(
            'CustomerAdded',
            response
         );
      };
   },
   'json'
);

What have we done? We've told Tab B, "Just announce that this event took place. Nothing more."

And Tab A? Tab A listens for that event.

$( '#TabA' ).bind( 
   'CustomerAdded',
   function( event, event_object ) {
      // refresh myself!
   }
);

It's called "bind" instead of listen, but it means the same thing. Now? Separation of concerns - check! And good things ensue.

For example, let's say another element on the page needs to know if a customer was added. Maybe there's a little rules engine that says "When a customer is added, the person adding them should be reminded to send them a hand-written 'Welcome' note."

Now, our rules engine can listen for an added customer without the code for adding a customer knowing anything about it -- especially helpful if the rules engine got added six months after the "add customer" code. As the Good Book saith: "Muck not with existing, tested code for in the day thou doest such an abomination, thy code integrity shall surely die."

That's the why.

Now, not to be like the good M. Fermat who once commented in a margin of a Math for Dummies or some such book that he had discovered a truly marvelous proof of a (seemingly-obvious, but really hard to prove) theorem, but which was just too large to include in said margin (to the near-eternal consternation of mathematicians), but this blog post is getting quite long.

Unlike Fermat's Last Theorem, which took over 350 years to be resolved, I intend to explain my solution tomorrow. But if you want just the raw code, you can "git" it here: http://github.com/halhelms/Blog-Post-Code.

Until tomorrow, then...