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:

com-qlikcookbook-ExportScript

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.