A Journey to My First Published Extension

Like Karl Pover, I’m curious to learn more about writing Qlik Sense extensions and other opportunities to use the Sense APIs.   I’ve created some throwaway examples in class, usually working directly in the Sense/Extensions directory.

I found I reached the point where I wanted to get a bit more serious about the mechanics of writing and maintaining Sense code. This post discusses some of my journey in discovering and implementing a structure for writing and publishing Qlik Sense extensions. (For tutorials on writing the actual extension code see Qlik Help or websy.io)

First, my extension project.  I like the script export/import function in QlikView script editor and have missed this function in Sense.  So I created a extension that provides buttons to Export and Import script to text files.





Yes, it’s true — a “Visualization Extension” that visualizes nothing.

You can click “Export Script” to send the current script to a text file, and “Import Script”  to replace the current script from a text file of your choosing. You can also drop a text file on the Import button.  You can find the extension with download links here.

On to the focus of this post, which is “how-to”.

Naming Conventions

As the extension landscape expands, how many extensions named “Super Bar Chart” will be created and published on GitHub? We need a naming convention that allows everyone to co-exist and avoid collisions.  I adopted the common open-source naming convention of prefixing assets with my reversed domain name “com.qlikcookbook”.   So the formal name of my extension is:


All my files; js, css, etc are prefixed with this namespace prefix. The “name:” property of the required .qext file provides a friendly name that will display in the Assets panel.  I chose the shorter “Export/Import Script” for the name.

An extension lives inside a larger application and must play well and share with others.  It’s not a good idea to name your html Div “output” as you may collide with others who use the same name.  I used the same prefix for any elements that may have a scope outside my extension, specifically html ids and css class names. The Qlik Help has some recommendations on this topic.

Directory Structure

I looked a a number of different directory structures on github that other folks had used for existing extensions.  I settled on the layout recommended by Stefan Walther in the documentation for his sense-go tool.  The design made sense and I was also interested in using the sense-go tool for building.

Loading External Libraries

I used a couple of external libraries in the project to handle the file download and the drag&drop function. Instead of referencing those libraries with html links, I learned how to use require.js, an integral tool in the coding patterns of Qlik Sense.  I also  used require.js to load my css and html files. It’s a great tool.

Building and Deploying

The standard way of writing code is to write your source code in one location and then prep and package the files into an installation or runtime bundle.  There are many advantages to following this pattern.  We also want a way to automatically redeploy the updated code to the Sense desktop or Server for testing, and upload a release package when ready.   As a starter build & deploy process, I chose Stefan Walther’s sense-go tool.  In addition to automating the process, I found  the task chain to be a good knowledge transfer from an experienced Sense developer.

Other Tools

Everyone has a favorite editor, I tried a few on this project.  I found I liked vscode best.

For managing the git repository,  I used GitHub Desktop.  You may like another tool or be a command line fan.

If you are starting out writing extensions, I hope these notes help give you some direction.

Note; This extension has been deprecated in favor of the DevTool extension which provides the same functionality and more. 


9 thoughts on “A Journey to My First Published Extension”

  1. Hi Rob,

    This extension fills a major gap in the product, which doesn’t seem to be getting plugged any time soon. I use another extension for reload from an app page for similar reasons.

    Like you were, I am still at the point of creating disposable demo extensions and nothing more.

    Thank you for sharing.

    For the record, I like the editor Atom…

  2. Great idea, Rob!

    Was looking for this kind of solution for a while and it really works well.

    Thank you,

  3. Hi Rob,

    Great extension for a gap in the product.

    I have a question about this extension – is it possible to view a script of an app which you don’t own (i.e. you are not the owner of the particular application)?


  4. Hi Rob,

    Thanks for your note.

    I have actually tried both extensions, and was only able to extract the Load Script file for apps which I own – even though i am Root Admin on QS. Note that when I duplicate the app of another owner, I am actually able to see their code.

    Would be great if you could double check what level of permissions you need though, or if I am missing something.

    Thanks again!

  5. Hi Rob,

    Seems like the same issue is brought over to the devtool extension. I’m not able to export the script for apps that I’m not the owner of.

    Did you get to check on the level of permission required?


    1. It does not appear that you can fix this with permissions. You can only extract the script if you are the app owner. It would be nice if the API returned an error instead of an empty string, but that’s the way it works today.

Leave a Reply

Your email address will not be published.