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
3. Stay in your sandbox
- do not inject HTML elements outside of your own element
- prefix your CSS rules so that it affects only the extension
- scan only your element, use $element.find() rather than $(), or element.querySelectorAll rather than document.querySelectorAll
- 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
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