Configuration Viewer Tool R3: Templates and Packaging

There’s two bits of progress to talk about this time around. Getting a template engine in place, and packaging the app up for distribution.

Template Engine

This was one of those occasions where I wasn’t 100% sure what I was meant to be searching for when looking for libraries to accomplish my goal. I started with “javascript component library” but didn’t see anything that looked too promising. After a while searching I settled on the term “javascript html template engine”, which brought me to a list of 2020s top libraries.

I glanced at a few of them before settling on Hogan. I don’t 100% remember the reasons behind rejecting a few of the ones higher on the list, but what was definitely part of the decision was the documentation showing how easy it is to use. Documentation and easy to follow examples go a long way to influencing the technology decisions that I make. If I don’t know how to get your library running in under 20 minutes, I’m likely to move on if there are other good candidates.

After picking Hogan, it was straightforward to transfer my messy inline HTML building into some simple templates. They’re probably not the best templates yet, but they’re functional and a lot neater than what was there beforehand. Displaying information about a field now looks like this:

Template

./resources/app/templates/field-info.html

<div>
    <h2>{{title}}</h2>

    {{#entries}}
    <p>{{.}}</p>
    {{/entries}}
</div>

Rendering

index.js (renderer file)

fieldInfoTemplate.render({title: title, entries: entries})

Broken down this template does two very simple things:

• Display the title parameter as a heading
• Loop through the provided entries array and display them

Super simple! But as the application builds in complexity, it’s great to break this out into template files and avoid a bunch of nasty inline code.

Packaging

When developing an Electron app you run it via npm which relies on node being installed. Running via npm is not acceptable for my target audience. A lot of the testers at the company I work for won’t know what node is, or why I’m asking them to run commands in it. To get around this issue electron apps should be packaged to include all necessary files and libraries in a standalone application.

Yeah, I didn’t know how to do that. To the search-mobile! The term this time was electron package app which lead me to a list of 3 recommended packaging tools.

I picked electron-packager as after a brief read through of each choice’s documentation, I thought it was the one I stood best chance of making work.

After doing an npm install on it, I tried out the packaging command and immediately failed, as I had no idea about some of the information it was asking for was.

electron-packager <sourcedir> <appname> --platform=<platform> --arch=<arch> [optional flags...]

What are the options for platform? What are the options for arch? Luckily when you hit enter on a plain electron-packager command it prints out a lot of information about the flags and all of their options. It let me know I needed platform=win32 and arch=x64. Boom. Packaged.

I packaged a version for windows, and one for Linux as well. I learned two things from seeing the application run in its packaged form:

• Don’t package your apps from the same folder as your source. Every time you repackage the app it will include all the files in your source folder including all the previously packaged apps. I was momentarily confused when my Windows app clocked in at about 100MB, and my Linux one was 200MB. Don’t be a silly goose like me: run the package command from outside your source folder!
• When your app is packaged your folder structure will end up being different: I stored the HTML template files in a subfolder of my source folder called ‘templates’ and referenced it in the code using ./templates/. Electron copies this folder to ./resources/app/templates while packaging. I “solved” this temporarily by moving the files in the packaged folder back to the structure I had during dev, as I wanted a quick solution that I could potentially demo to colleagues. This is bad, but I was in a rush. The eventual fix will be find a way to reference the resources folder through code.

I ended up not demoing the application in the end, as there wasn’t time. I’m planning to get feedback on it very soon though, as it will be invaluable in shaping what the tool ends up becoming.

Featured image: Photo by Guillaume Bolduc on Unsplash