function UpdateOutput() {
    var name = $('#txtName').val();
    var address = $('#txtAddress').val();
    var city = $('#txtCity').val();

    $('#output').html(name + ' ' + address + ' ' + city);
}

$(document).bind('NAME_CHANGE ADDRESS_CHANGE CITY_CHANGE', function() {
    UpdateOutput();
});

$('#txtAddress').keyup(function() {
    $(document).trigger('ADDRESS_CHANGE');
});
$('#txtCity').keyup(function() {
    $(document).trigger('CITY_CHANGE');
});

$('#txtAddress').keyup(function() {
    UpdateOutput()
});
$('#txtCity').keyup(function() {
    UpdateOutput()
});

2 Responses to “Custom events and event pooling in jQuery – What’s the point?”

1. Michael Hamrah says:

   June 7, 2010 at 11:10 pm

   It’s perfectly reasonable to wire up the UpdateOutput() call directly. Often, it’s difficult to represent the need for an abstraction that custom event pooling provides in simple examples.

   However, there’s one (arguable) two issues of maintainability (again, depending on the use) when calling UpdateOutput directly. The first problem occurs by repeating the UpdateOutput() call in numerous places. This makes refactoring functions (especially those with parameters) extremely difficult when they change. With Event Pooling, you can prep data before passing it to a function, which is helpful when disparate code blocks call the same function. With ajax heavy web apps around, controlling function calls is very important.

   Secondly, it’s possible you’ll need to couple multiple functions for the same event. Imagine in addition to UpdateOutput(), there’s also some validation function which needs to be fired. Or when a user updates the zip code, some maps api is trigged to show something, or whatever other functionality which could happen (the point being you may have numerous functions being called in a simple keyup() event. Having this wired up directly makes for very large blocks of code which simply call multiple functions, and if there’s conditional logic required, they can get out of hand. Rewritten with event pooling, you get a lot more control of how a function like UpdateOuput is being called, so you don’t need to chase down the method across numerous files. You can simply see what events that cal is binded too.

   Reply
2. Michael Hamrah says:

   June 7, 2010 at 11:13 pm

   Sorry for the typos, should have proofread. Second paragraph should be “However, there’s (arguably) two”. Third paragraph should read “it’s possible you’ll need to call multiple”. Updated text below:

   It’s perfectly reasonable to wire up the UpdateOutput() call directly. Often, it’s difficult to represent the need for an abstraction that custom event pooling provides in simple examples.

   However, there’s (arguably) two issues of maintainability (again, depending on the use) when calling UpdateOutput directly. The first problem occurs by repeating the UpdateOutput() call in numerous places. This makes refactoring functions (especially those with parameters) extremely difficult when they change. With Event Pooling, you can prep data before passing it to a function, which is helpful when disparate code blocks call the same function. With ajax heavy web apps around, controlling function calls is very important.

   Secondly, it’s possible you’ll need to call multiple functions for the same event. Imagine in addition to UpdateOutput(), there’s also some validation function which needs to be fired. Or when a user updates the zip code, some maps api is trigged to show something, or whatever other functionality which could happen (the point being you may have numerous functions being called in a simple keyup() event. Having this wired up directly makes for very large blocks of code which simply call multiple functions, and if there’s conditional logic required, they can get out of hand. Rewritten with event pooling, you get a lot more control of how a function like UpdateOuput is being called, so you don’t need to chase down the method across numerous files. You can simply see what events that cal is binded too.

   Reply