Launch – Make an Extension – Debugging

Here comes part 3 of the mini series on “Making a Launch Extension“. We looked at the setup and the coding. Today we discuss debugging.

I’m sure you are way better than me when it comes to writing HTML and Javascript, but I’m also sure whatever you write is unlikely to work first time round. So test you must.

To do so, there is a sandbox, which actually runs on your machine. You can install it via npm, and if you have set it up properly, a simple npm run sandbox will launch node.js and your sandbox.

Install it like so:

	npm install @adobe/reactor-turbine @adobe/reactor-sandbox --save-dev

Then follow the advice to add a script into your package.json, it’ll make your life a lot easier.

My package.json looks like this now:

{
  "name": "sample2",
  "version": "1.0.0",
  "description": "Sample package",
  "main": "index.js",
  "scripts": {
    "test": "echo \"Error: no test specified\" && exit 1",
    "sandbox": "reactor-sandbox"
  },
  "keywords": [
    "launch"
  ],
  "author": "Jan Exner",
  "license": "ISC",
  "devDependencies": {
    "@adobe/reactor-sandbox": "^8.2.0",
    "@adobe/reactor-scaffold": "^1.1.9",
    "@adobe/reactor-turbine": "^23.1.0"
  }
}

You can now run the sandbox by simply typing:

	npm run sandbox

[screenshot]
Successful npm run sandbox
You can hit it on localhost:3000, and it looks somewhat like this:

[screenshot]
The “View Sandbox”
The part in the white box on the left is the view that you built, and which, once your Extension is out there, people will use to configure it.

On the right hand side, you can see and test the functionality of your view. Try initialising your extension, using getSettings, or check if your validation works.

Happy with your UI? Time to check the extension actually delivers!

If you click through to the “libSandbox” the first time, you won’t see much.

[screenshot]
The “Lib Sandbox” (still empty)
This is because you need to write a test bed into which Launch can load your library code. It is up to you what that test bed does.

It probably makes sense to provide something here that looks like a page on your site, that way you can see what happens when Launch injects your page code.

I’ll write one that simple reads the Data Element I built.

In libSandbox.html, I replaced everything from line 25 down with this:

  <p>Check out the value of my Data Element: <span id="mycde"></span></p>

  <script>
    _satellite.pageBottom()
  </script>
  <script>
    var mycde = _satellite.getVar("constantDataElement");
    var mySpan = document.querySelector("#mycde");
    mySpan.innerHTML = mycde;
  </script>

And in container.js, I added my Data Element to the “dataElements” section, like so:

  dataElements: {
    // Set up data elements that you would like to test. The top-level object keys are the data
    // element names. For each data element:
    //  - modulePath is the name of your extension (as defined in your extension.json) plus the
    //    path to the library module file.
    //  - settings is an object containing user input saved from your extension view.

    // productId: {
    //   // This is a simple data element type provided by the sandbox which retrieves a value
    //   // from local storage. This data element type is provided as a convenience in case
    //   // your extension does not have any data element types of its own.
    //   modulePath: 'sandbox/localStorage.js',
    //   settings: {
    //     // The local storage item name.
    //     name: 'productId'
    //   }
    // }
    constantDataElement: {
        defaultValue: "",
        forceLowerCase: !0,
        cleanText: !0,
        storageDuration: "pageview",
        modulePath: 'sample-extension-2/src/lib/dataElements/constantDataElement.js',
        settings: {
            name: 'My Constant Data Element',
            value: 'it\'s super!'
        }
    }
  },

Note the modulePath, which is a combination of the name element in extension.json, plus the path towards your JS file. Also note, that in your test, you can read the Data Element not by it’s name, but by the root element (in my case, _satellite.getVar("constantDataElement") will work).

Together, those changes lead to the following output:

[screenshot]
The “Lib Sandbox” (functional)
It works!

By the way: you need Internet connection while using the sandbox!

The sandbox itself runs on your machine, but it loads quite a lot of assets from the Launch servers, so without Internet, it’ll look ugly, and it won’t work.

By now you should have everything you need to be able to go around in circles of develop / debug / pull hair / fix, and with that, I close this mini-series.

How about deploying your extension, you ask? I frankly don’t know yet how to do that. So that article will have to wait a little bit, I’m afraid.

4 thoughts on “Launch – Make an Extension – Debugging

  1. Nice post Jan! Note that in your library sandbox example, the “name” property in your settings object (name: ‘My Constant Data Element’) isn’t necessary. I’m guessing you may have copied the “name” property from the commented out productId example. In that particular example, “name” is user-defined name of a local storage item. The local storage data element type then uses the name to look up and return the appropriate item from local storage. In your case, since your library module doesn’t use “name” for anything (only “value”), it’s unnecessary. I hope that makes sense. Let me know if it doesn’t. Thanks for the great content!

    Like

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s