Part 2 of the “Make a Launch Extension” mini series is about the actual coding.
You can find the other parts here: setup, debug, publish.
This article is split in two parts, aligned with the two different parts the extension has to provide: UI and actual JS code. Let’s start with the UI.
UI
Your extension can, when users add it to their Launch configuration, provide a view that allows them to configure the extension.
For our example, the view will provide an input field. The user can put a value into the field, and that value is what our Data Element will return when queried.
More complex extensions will likely have more complex configuration. There really is no limit to what you can do here. There are a couple of things that you must do, though, and I would strongly urge you to show some restraint and keep the configuration as simple as possible.
Here is the HTML that I came up with.
<!doctype html>
<html lang="en">
<head>
<meta charset="UTF-8">
<title>Constant Data Element</title>
</head>
<body>
Constant value:
<input id="value" type="text">
<p><em>Please note that the value can not be empty, 0, false, or any other 'false-y" value</em></p>
<script src="https://assets.adobedtm.com/activation/reactor/extensionbridge/extensionbridge.min.js"></script>
<script>
window.extensionBridge.register({
init: function(info) {
if (info.settings) {
document.querySelector("#value").value = info.settings.value
}
},
getSettings: function() {
return {
value: document.querySelector("#value").value
}
},
validate: function() {
var value = document.querySelector("#value").value;
var valid = false;
if('undefined' !== typeof value && value && value.length > 0) {
valid = true
}
return valid
}
});
</script>
</body>
</html>
As you can see, the actual input field is a single HTML <input> tag. I added a paragraph below it with a bit of explanation.
For this simple HTML to become a view, it then loads the extensionbridge.min.js script and registers an extension bridge.
That bridge must provide three functions: init, getSettings, and validate.
I guess this is pretty straight-forward, but: init is called when the view pops into your browser. It can and should be used to populate all configuration options with either defaults or the settings the user made the last time. getSettings is used by the bridge to read the user input. validate should return true or false, and the bridge uses it to check whether the configuration is valid. It won’t save if it isn’t, of course.
What you put into those three functions is up to you.
I am evidently not doing the right thing above. When the extension is added and the configuration pops up for the first time, the default for my input field is empty, which in turn means it won’t validate. That can be a frustrating user experience, so please, kids, don’t do this at home.
One more thing to note: I did not style my input field or anything else. I resisted the temptation to load Zurb Foundation or some other framework and make my view look awesome. So should you! Trust Launch! Don’t make a UI that looks out of place within Launch!
The documentation for Views has some more information.
Javascript Code
The second part of your extension is the Javascript code that Launch will inject into all pages.
For this sample project, that JS code is almost criminally simple:
'use strict';
module.exports = function(settings) {
return settings.value;
}
The simplicity is due to the fact that the sample extension provides only a Data Element. The only thing the Javascript has to do is to return a value. And since this one returns a constant, stored in the configuration, all it has to do is return that value.
If your extension provides Events, Conditions, or Actions, your Javascript will look different, but probably still realtively simple.
There are a bunch of Core Modules that you can use when you write your extensions, with functionality such as managing cookies, or using query strings more easily.
Web Analytics for Developers 
4 thoughts on “Launch – Make an Extension – Coding”