Month: October 2019

I’ve been using the Jest testing framework in a side project. One of the areas I needed to test required that I populate data in my MongoDB database so that there was something for the tests to run against.

I had some debate in my mind between using beforeEach(), which does the database population step before each individual test is executed (once for each test), or using beforeAll(), which does the database population step one time before the tests are run collectively.

BeforeAll() seemed like the more efficient–and therefore quicker–way to do things because it would involve fewer calls to the database, but I ran into a circumstance where that was making writing a couple of the tests more difficult.

In testing however, I found that there wasn’t any consistent difference in speed between using beforeEach() and using beforeAll(). I don’t know if that’s because Jest is running the tests asynchronously and therefore the wait while the database is populated is mostly overlapping for each of the tests, or if Jest is doing something where it doesn’t actually run the beforeEach on tests that don’t read from the database, or if there is something else entirely going on there.

The key takeaway for me was that it didn’t matter (from a performance standpoint) whether I used beforeEach() or beforeAll(). As a result, I’ll be using beforeEach() because it makes writing tests slightly easier.

This week I had an instance where I created a custom table, and then had to come back and add an additional field/column to it. After doing so, I could no longer get the table to display in list view.

Other users were still able to see the table and the data on it, so I knew that it was still there.

In the end, running cache.do in the application navigator did the trick of clearing my cache and allowing me to see the table.

In my previous use cases where I needed to use a UI Page as a modal on a form from inside of ServiceNow, I was just displaying information.

That meant the job of closing the modal/UI Page rested squarely on the shoulders of the user.

In my most recent project (unfortunately something that will have happened months previously by the time this post is published), I needed to have the UI Page be close automatically after the user clicked on a button.

The proper line of code to close a dialog window is:

GlideDialogWindow.get().destroy();

That was fairly easy to find, but I was surprised to find that you can’t just call that anywhere from inside of the client script on the UI Page.

I’ve seen in the past some instances where the call stack inside of ServiceNow doesn’t seem to behave quite the way I would expect it to based off of my experience with other JavaScript environments. I can’t point to any specific examples, or remember for sure what I was working on when I ran into the odd behavior, but that recollection that I’d had problems previously caused me to place the .destroy() call inside of my callback function.

(I was using a GlideAJAX to drive back-end behavior from the UI Page, which necessitated the use of a callback function to parse out the XML response from the GlideAJAX.)

It appears that you’ve got to place the .destroy() call inside of the main client script function inside of your UI Page for it to properly close out the UI Page.

In my instance, placing that .destroy() call after the .getXML(callbackfunction) call meant that the callback function had been cleared off of the call stack before execution flow got to the .destroy() call, so everything worked, but I was surprised that I couldn’t call .destroy() from inside of the callback function.

As I discussed in my last post, I’ve worked with UI Actions to call UI Pages previously. However, during this most recent project, I was seeing odd behavior where when I would click on the UI Action, the page would be redirected to the page where the UI Page is defined rather than just staying on the current page and popping up a modal.

Even more surprisingly, when I hit the back button to go back to the form from which I’d click the UI Action, I would see the UI Page pop up as a modal.

As it turns out, this behavior is caused when you haven’t defined the UI Action in question as being client callable.

So, if you ever have a UI Action that is redirecting to the UI Page rather than displaying the pop-up, double check that you’ve clicked the ‘client’ box on the UI Action definition.

I recently found myself needing to have a UI Action pop up a modal which would accept user input and then go perform various actions depending on what user input had been received.

I created the UI page, and then rendered it using something like this:

var dialog = new GlideDialogWindow(‘UI_Page’);
dialog.setTitle(“Page Title”);
dialog.render();

That is fairly basic, and is something that I’ve done previously, but something that I hadn’t realized before now is that in the client script of the UI Page, it’s possible to use g_form calls.

In essence, it appears that a UI Page (at least one called from a UI Action which is in turn called from a form) has access to the same context/namespace as the underlying form which was used to call the UI Action.

Now that I’ve written that down, I’ll remember it for the next time that I need to do something more complicated with a UI Page.