Configuration Viewer Tool: Progress Report 1

Progress on the configuration viewer test tool I described in my last post is going well so far. Electron is proving to be a great platform for quickly prototyping and developing this kind of tool.

Because Electron is essentially a web browser, there’s very little wasted time when making alterations to the code. So far I’ve been able to hit Ctrl-R (refresh) and see all of my functional and layout changes immediately. That’s a big improvement from JavaFX, which is what our previous GUI tools have been written in.

Dragging and Dropping Files

Point one on my first steps list was to get dragging and dropping of files implemented. I feel this is an essential, day 1 feature, as usability is the key to success with any tool. It can be powerful and feature-rich, but if nobody can stand using it, it will just gather dust.

Dragging and dropping proved reasonably easy to implement, with a few searches for the type of events that are being fired off while a user is dragging files around near a JavaScript application.

One issue I encountered was that I initially attempted to use the dragenter and dragleave events to do some style changes to make it more obvious when a file could be dropped into the application.

When dragging a file over the application body it would correctly change, and when dragging it off the body it would change back. But if any child element was hovered over it would fire a dragleave event and act as if the user was no longer dragging a file over the application.

The events were added to the document itself, rather than any specific element. I was expecting this to only run code when the document body fired a dragleave event, but it turns out that’s not how it works.

After a brief internet search, I was happy to find this is a fairly common problem, having been around for at least 8 years now. The solution I implemented was to check that the element being left was the document body, and only remove the styles when that’s the case.

document.addEventListener('dragenter', (event) => { 
    dragBody = event.target
    document.getElementsByTagName("body")[0].classList.add('body-hovered')
}); 

document.addEventListener('dragleave', (event) => { 
    if(event.target == dragBody) {
        document.getElementsByTagName("body")[0].classList.remove('body-hovered')
    }
    
}); 

This may need a better solution, but it works for now.

Other than that it was just a matter of storing the contents of the dropped file, and adding some basic validation to make sure we’re working with a JSON file.

Displaying Fields In A User Friendly Way

I’ve not done too much work with this yet, as I’m still in the process of figuring out what information I want to display. Knowing the important information that people are going to use the most often is instrumental in making the application useful to our testers, so I’m not rushing it.

So far, when the application processes the dropped file it displays the IDs of each field in a list. This lets me know that my basic drag and drop events, as well as my file processing functions, are working correctly. It’s enough to get started on other things.

Filtering Fields

Being able to filter through the mass of information is going to be super important for usability. If it’s not easy to find what you need, it’s going to be no better than reading the JSON file.

I’ve implemented 3 hard-coded filters so far, ones which I know from experience will display crucial information. These are:

• All fields (okay, this isn’t important, but you should be able to get every field back if you want to!)
• Registration fields – Only shows fields that a user needs to enter to be able to register using our application.
• Integration fields – Most of our applications are only available to users who have been invited by our clients (think of it as a perk of being one of their customers). Integration fields are what allows a registration attempt to be matched with a known customer of the client. It’s important for testers to be able to quickly identify the fields that we’re requiring a specific client to send to us.

These filters are implemented in a really basic way. Click a link and it’ll run a function on the fields (stored in a JSON object) to check for ones that have a specific key/value and render them to the screen.

There’s some fairly gross code going on (what’s with that oldschool for loop, Will?), but this is the general gist of the filtering right now:

    for(var i = 0; i < json.fields.length; i++) {
                field = json.fields[i];

                if(field.user_input?.forms?.REGISTRATION) {
                    showFieldData(field);
                }
            }

I think there’ll be a lot of cleaning up to do, but while I’m prototyping stuff I don’t want to spend too much time worrying about small things.

Next Steps

The first thing I want to look into is data persistence. Currently the application forgets everything the moment it’s refreshed. I think it should be able to remember what configuration was loaded, even after the application is closed and re-opened.

Then I want to look into how I want to display some of the important information that a field can have. Things like:

• ID
• Registration form name
• Integration name
• Where it’s stored in the database
• Field validations

I think this could be tricky, and there may be a lot of conditional logic. Not all fields have the same information, and some information becomes more relevant for certain types of fields. It’s integral to how useful the tool will be though, so even if I don’t immediately solve every issue, I want to at least want to know what those issues are so I can think about solutions.

Next up is displaying the raw JSON for a particular field. While the purpose of the tool is to make things more readable and focused, I think having a way to view the JSON for one field at a time will be useful. I’m thinking this may be an alternative view to the important information one. Like an “advanced user” view.

Featured image: Photo by Marcel Friedrich on Unsplash