The extension is now included in the dashboard bundle, available with the Qlik Sense installation, and available in Qlik Open Source repositories. It is also supported by Qlik.
This has been a fun project to work on, the functionality it brings was something many customers wanted, and it quickly became one of the most commonly used extensions. It was first realeased over four years ago, in the first days of 2015.
The fact that Qlik now delivers a set of extensions with the product, and supports them, is of course great for customers. One of the few frustrating periods during the last years was when there was a Qlik Sense version that actually broke the extension. That will not happen again.
Thanks to everybody who has contributed to the project with suggestions and in some cases even some code!
After more than two years at IKEA, my work with them has now ended. It has been a fantastic journey, with the introduction of a global Qlik Sense dashboard with support both for desktop and mobile and a set of Qlik Sense extensions with the IKEA profile and covering their needs (well, perhaps not everything, but quite a lot of them). I am very happy to have been a part of this, I think we have been able to do amazing things.
My work at Qlik continues. The Advanced Authoring project moves forward, hopefully you will see some really interesting stuff in upcoming Qlik Sense releases. Looks like I will continue helping them a few months more. After that I’m not yet book, so if you ahve an interesting project starting after the summer where you need help with Qlik Sense development, please let me know.
Apart from that I’m in some discussions about other work in the Qlik Sense area And of course, I’m preparing for Master Summit in Stockholm!
I’m really happy to be guest speaker when Masters Summit for Qlik comes to Stockholm in April. For those of you who have not heard about Masters Summit, you should really check it out. I took part in Boston in 2017, and it was truly a great event.
API track
In Stockholm they are adding an API track, for developers working more with build applications, mashups and extension using Qlik Sense API’s and Qlik Core. Great content and led by people that really know what they are talking about. And with me in a short session on Qlik Sense use of web sockets….
I am happy to tell you that with Qlik Sense november 2018 this is now obsolete. In most cases you don’t need to do anything to have alternate state support in november 2018, it will work out of the box. For example the wordcloud extension:
You will get a new section in the property panel where you can set the state to use. The default setting, ‘inherited’ will mean that the chart will inherit its state from it’s parent (currently the sheet), but you can also specify what state you want.
November 2018 also includes support for managing alternate states and the selection toolbar shows selections for all
One of the new features of Qlik Sense november 2018 is the bundled extensions. If you install the bundle that’s included with the release (and I think you should) you will get a couple of extensions, one of them based on my qsVariable:
Based on, because Qlik has renamed it and made some modifications. Since it has a new name your existing apps that uses qsVariable will continue to do so, you will need to convert them to use the bundled version: You should probably do so, since Qlik will maintain the new version, and test and possibly fix it for new Qlik Sense versions.
A common mistake when you start with Qlik Sense extensions is to forget about setting Initial data fetch in your extension. Typically you would include something like this in the initialProperties of your extension:
That would work, and make sure your extension gets the 500 first rows of data in the layout provided to your paint method. But sometimes you want the app developer to be able to set the number of rows fetched. In that case you can simply add the qHeight parameter to the property panel like this:
And the result is a new section in the property panel, where the app developer can set the number of rows initially fetched.
When you work a lot with something you develop opinions about how things should be done. Here is my list, after two years as an independent contractor, mainly with Qlik Sense extensions and mashup, and of course based on my experience from Qlik.
1. Use version handling
There is no reason not to use version handling of your code. I use Git for everything, but if you are still using something else, that might be OK too. You probably should consider switching to Git, but as a developer that might be a decision taken over your head.
The benefits of using version control are enourmous. You can easily go back and find the reason behind a bug or the implementation behind that feature the customer now wants in another extension too. Invaluable!
You also should keep a version number in your qext file, and change it every time you deploy a new version. The main benefit of this is that you can see what version of your extension is in use in a Qlik Sense installation. I have described how to do this in a previous post.
2. Always test your extension in a browser
The developer console is an excellent tool for extension development. You use it to debug your javascript code, to inspect the HTML and CSS and to analyze the network traffic, including the web socket traffic. It can also be used to turn caching off, so you know that you are running the latest version. The browser included with Qlik Sense Desktop is not of much use for extension development. Even if you can open the console, it’s an environment your users do not use.
3. Stay in your sandbox
The extension framework gives you a HTML element for your extension. Stay inside it, unless you have very good reasons not to do so. That goes both for your javascript and CSS.
do not inject HTML elements outside of your own element
prefix your CSS rules so that it affects only the extension
avoid html id’s, since they must be unique within the page. If you must use one (really only when you use a library that needs an id) make sure they are unique for each extension instance (test with multiple instances of the same extension)
There are occasions when you need to break theses rules, but only do it when it’s need for your extension functions.
4. Use modern development tools
Pretty soon after you have started with extension development you will grow out of the Qlik Sense dev-hub extension editor. A modern, nodejs-based environment, with a good text editor gives you a lot of benefits, and works well with version handling software. I would recommend the following:
a good editor. I mostly use Visual Studio Code, but there are others that probably are just as good.
a CSS preprocessor like less helps you with prefixing css, add vendor prefixes etc
a lint tool, to find common errors an enforce good programming practices
possibly a preprocessor, to allow you to use modern javascript features and still work on older browsers
5. Always keep your extension backwards compatible
After a while your users will most likely want more functionality in your extension. They might want more interactivity, more rendering options, perhaps support for more dimensions and measures. You will probably add new settings giving your extension more flexibility. You might also find that some of the stuff you originalyy programmed was not perfect (that happens to all of us..). But if you have deployed your extension to production, make sure that all your changes are backward compatible. If you don’t you will have huge problems when you deploy the new version, with breaking apps.
If you find it impossible to make your new extension backwards compatible you probably should not be making a new version, but a new extension, with a different name.
6. Base your rendering on only the layout
The model behind Qlik Sense extensions (and the built-in charts too, actually) is that the extension is based on a Generic Object, where you configure the Generic Object in the property panel and use the layout for rendering. Stick to that model, do not break it. If you need more data for your rendering, add it to the properties structure. Avoid:
creating HyperCubes and ListBox objects programatically, add them to initialProperties and the property panel instead
fetching variable values programatically, add expressions to the property structure instead (that also gives the app developers more options, like hard-coding values, or making them change automatically as selection state (or data) changes
It is however OK, even recommended, to call API methods for:
showing lists of available values in the property panel
making selections etc when the users clicks on buttons, menues or other parts of your UI
call the Engine API method doReload(). Use this in Qlik Sense desktop, since it’s the only method available.
use the repository call App reload optionally with the help of the callRepository method. This is of course only relevant in a server installation.
You’ll find code examples in my original post, and also how to know if you are running in server or desktop.
What happens when you use /app/reload ?
While this method works well in some scenarios, like when you just want to run one reload of an app ASAP, it has some limitations. Behind the scenes Qlik will create a very simple task for you, and try to start it immediately. The task will look like this:
Very basic, just an app, a name, an the default Task session timeout of a day (or 1440 minutes). No triggers, since the task is started by the REST call, no tags, no custom properties. And, perhaps most important, no retries. This means that if you create a series of reloads this way, most likely only the first few will succeed, the rest will fail since there is no engine instance available.
Another method to start a reload
But there is another way to do it. You can easily create the Task yourself, and set whatever parameters you need. Qlik Sense QRS API is really easy to work with, and the callRepository method can help you by fixing the xrfkey and wrapping the call in a javascript Promise. So creating a reload task can be made as simply as this:
This will create the reload task the way we want it and return the id for the task, whish we can use to start it. That’s just another call to the Repository like this:
And that’s it. A little more code than the second method, but much more control over what we get.
You have been running Qlik Sense for a while in production, with multiple apps, some extensions and mashups. Or, you are just starting to work on a Qlik Sense site, where you don’t really know what has happened before. And perhaps the extensions you are using in development are missing or they seem to be of an older version. How do you find out what is on the server?
Whenever you are running Qlik Sense, whether it’s the standard built-in client or a mashup, the client will call the server to find out what extensions (including mashups) are available. This call has the format:
https://[server]/[proxy]/qrs/extension/schema (+ xrfkey in server installation)
The reply you get is in JSON format, and contains all extensions available with their id (the qext filename) plus the contents of the qext file. It’s quite readable and when you look at it in the developer console you can expand the lines you are interested in.
This will give you the extension version number, provided you keep a version number in the qext file, which of course you do.
The property panel is a key part of your Qlik Sense extension. The aibility to set extension properties is what makes your extension both reusable and flexible. At the same time your options are much more limited than in the rendering part of the extension. And since this is Qlik Sense specific all of it, there is not so much information and examples available on the internet. So here are some patterns and techniques I find useful in extension development.
1. Use expressions always
Strings in the property panel can allow Qlik Sense expression by setting “expression: ‘optional’ “. Use that – always. This allows the app developer to use expressions for the property and thereby make the property dynamic. It also allows the app developer to reference a variable and use a variable extension to allow the end user to switch values for the property (horizontal/vertical for example).
It allows the app developer to use an expression, but doesn’t force her. Still a fixed string can be used, and probably will be used. And the good thing thing is you don’t have to bother about that in your extension code, you get this flexibility for free.
2. Dropdown with custom alternative
Sometimes you have just a few possible values for a property, or you want to help the app developer with a list of common values for a property. The dropdown component is a good choice for that. But you risk loosing the flexibility of the expression: the dropdown will only make it possible to select a value at design time, no possibility to make it dynamic or affected by a variable. Or the list is really not a complete list, there are alternatives for the more advanced app developer.
In those scenarios you can combine a dropdown with a separate field that allows expressions like this:
create a dropdown with your alternatives
add a ‘custom’ alternative to the dropdown
add a field with expression: ‘optional’ for the custom value
give the field a show function, that returns true if the selected value is ‘custom’
In your extension code you will need to check for custom values, something like this:
var width = layout.width === ‘custom’ ? layout.customwidth : layout.width;
3. Add properties to dimensions and measures
Sometimes you need a property for every dimension or measure. In that case you can extend the built-in dimensions and measures objects by adding new properties. You do this simply by setting the items property to the properties you want to add, and Qlik Sense will merge the default properties with the ones you hav defined. An example:
Note that the ref should begin with ‘qDef.’. That will mean it will be part of the measures property. To the app developer your roperty will look just like the built-in ones. You can do the same thing with dimensions.