How to introduce Google Analytics code in a modular way?

Question

We are working on a very large codebase. It's basically a web-based operating system, with its own file system and applications. The system's UIs are generated dynamically with Javascript.

We've decided to introduce Google Analytics to track various user activities.

Our concern is that in order to send data to Google Analytics servers on these events we'd have to scatter analytics code in all event handlers. Even if we wrap the analytics calls in a module, we'd still have to call it. E.g. usual code:

$(importButton).on('click', function() {
 // ... call import module to do import stuff
})

becomes, roughly speaking

$(importButton).on('click', function() {
 // ... call import module to do import stuff
 analytics.registerEvent('import')
})

And so the analytics code becomes extremely tightly coupled to the interface logic.

How do we introduce analytics in a modular fashion, without scattering analytics calls over all event handler functions?

• Doval: Replace .on with a function that registers the handler but also calls analytics behind the scenes?
• scriptin: @Doval that's ill advised unless you need mocking. Since most of the time this additional functionality won't be needed anyways, that's just additional cost of calling a mocked method.

Answer 1

You don't have to change existing code, because you can just add more event handlers. JavaScript naturally supports multiple event handlers on a single element, and it's even easier with libs/frameworks like jQuery:

// in existing code:
$('#button').on('click', function (event) {
 console.log('normal behavior');
});
// somewhere else:
$('#button').on('click', function (event) {
 console.log('user tracking');
});

This does not affect performance significantly and you can always improve it with event delegation.

• Stas Bichenko: What if the button's function depends on outside conditions? For example, a "Create new" button may create different types of files depending on a menu setting.
• scriptin: If possible, event should occur on concrete action, or be composed of several simple events: e.g. "button clicked" followed by "window opened". That fits a definition of goal. Also you can check those outside conditions the same way as in existing code. If, however, you need something more complex, you'd have to modify you code anyway to produce some kind of custom events with additional state. In that case, you'd have to modify your code anyway, and I don't think there is a way to avoid that. Complex problems have complex solutions.