Launch Extensions & Cato Fong

Some time ago, I built and released an Extension called “Time spent and Scroll Depth“, mostly as an exercise for myself, and because I thought Simo Ahava had really nicely explained how tracking content-heavy sites might work.

Since then, I have learned a lot, and I sort of don’t want to look back at the code I wrote in the dark ages, you know, the usual.

But the Extension has a real problem, a problem that a lot of Extensions have, which is that you cannot en- or disable it explicitly for specific sets of pages.

If you add the Extension and use it, the code will be on every page that uses your Launch Property. There is no way, in Launch, to enable/disable Extensions per page.

Hm…

Clouseau

Inspector Clouseau, in the 1970s Pink Panther movies, had the splendid idea of instructing his side kick, Cato Fong, to keep him on his toes by attacking him, randomly.

In the movies, Cato, played by the late Burt Kwouk, usually attacks Clouseau at the most awkward and inopportune moments, just as instructed. Their fights often wreck parts of Clouseau’s appartment, and they usually end because the phone rings or someone knocks at the door. Clouseau often “wins” the fights by hitting Cato when he is finished with the call.

This is relevant, believe it or not, to Extension development and Launch.

When you build an Extension for Launch, you can extend the functionality via a bunch of different elements, such as Action Types, Data Element Types, Condition Types, Shared functionality, and, Event Types.

The latter are the Cato Fong of your Extension, the Cato Fong of the Launch eco system, or, if you want, the Cato Fong of web development.

Event Types are used to trigger Rules in Launch. Just like Cato Fong, the triggers behind those Event Types can happen at any time.

Light bulb

When I first wrote about the different elements that you can add to Launch, I noticed that unlike Data Element, Condition, or Action Types, Event Types were not actually tied to Rules.

Event Types live in the general context of Launch, not inside a Rule. They have to, because, just like Cato, they must be ready to trigger at any time.

The light bulb moment came a lot later: because of this, the code that implements any Event Type must be present no matter what.

There is no way around this fundamental reality: if you want to be able to react to something, that ability to react must be present.

In the context of Launch, Javascript, and web development, that means an event listener must be present, whether a Rule would actually use it or not.

To go back to the example at the beginning of this article, my “Time Spent and Scroll Depth” Extension: even on pages where I really don’t care, the scroll depth listener would have to be present.

Awkward.

A better way?

Theoretically, Launch could analyse your code.

It would have to check all Rules, find the ones that potentially might fire when your Event Type triggers, check Conditions inside those Rules, and then, maybe, decide that the Event Type wasn’t actually needed right now.

My feeling is that this is a lot of effort for a marginal gain.

So it is unlikely that the Launch team will build it.

Can we work around this?

The question “Can we load an Extension conditionally?” has come up a lot.

The answer is: no, but it might not be as bad as you think.

Rules can have Conditions on them, and so the only real problem are the Event Types, and code in a main module, should the Extension provide one.

For some Extensions, it might be possible to change the logic, and so the real answer to the question is: well, it depends on the Extension.

The Extension will always load, but depending on how it was built, that may or may not be a problem. Aaron Hardy wrote about the flow, if you’re interested.

Back to my own Extension, and the scroll listener that is added on every page…

I could rebuild the Extension so that the scroll listener must be explicitly injected into the page using an Action Type.

The scroll listener would still have to be able to trigger Rules, but it could do that via a Custom Event.

Given that the Custom Event Event Type is part of the Core Extension and therefore always present, this would work, and it would also not add any unnecessary complexity.

And there you are, yet another thing to keep in mind when you build an Extension…

Thank you for you cooperation.