Taking a Deep Dive into the Next Experience Developer Tools

Posted on BY

ServiceNow recently announced a new Chrome extension, Next Experience Developer Tools, for debugging and profiling Next Experience Framework components and workspaces. After watching Episode 10 of the You & I Builder series, where I was introduced to the extension, I decided to play around with it myself!

In addition to a summary of the extension’s features, you’ll also find a list of my personal favorites at the bottom of this article. If you want a quick peek into the capabilities of this extension but don’t want to read the full list of features, go ahead and jump to that list of favorites!

Overview

Setting up the extension is very easy. Here are the steps I went through to use it on my browser:

  1. Find the Next Experience Developer Tools extension in the Chrome Web Store and then click “Add to Chrome”
  2. Open a page in your instance that uses the Next Experience Framework (like a Workspace)
  3. Open your browser’s developer tools
  4. Expand the list of developer tool tabs to see the newly added “Next UI Inspector” and “Next UI Profiler” tabs (see image below)

Features

The Next Experience Developer Tools makes two new tabs available in the browser developer tools: “Next UI Inspector” and “Next UI Profiler”. Each tab offers a subset of tools to make developing and debugging Next Experience pages and components easier.

Next UI Inspector

The “Next UI Inspector” tab can used to inspect component properties and actions on a Next Experience page.

Components

The “Components” tab lets you search for and/or select Next Experience components on the page. When a component is selected, you can view its properties, state, action handlers, and triggered actions.

  • Properties – The configuration options that can be set on the component. These properties correspond to the “Config” tab options that are available when setting up a component in UI Builder. The values shown here are the back-end values stored in the JSON for the component instance definition. If you want to test other values for a specific property, you can double-click the property’s value and edit it according to the schema shown on the edit page (see image below).

  • State – The internal state of the component. For example, a Modal component contains state values pointing to the triggering element, the modal data itself, and the modal behaviors.

  • Action Handlers – A list of the action handlers that are bound to the component.
  • Actions – Actions that are triggered by the component. For example, if I click a button, NOW_BUTTON#CLICKED is recorded in the “Actions” tab, along with its payload and metadata.

Actions

The “Actions” tab lets you see actions that have been triggered on the page, along with their payload and metadata. From the “Actions” tab, you can also filter out or dispatch certain actions.

  • Dispatch – The “+” button lets you dispatch an action from a component on the page. Once dispatched, you are taken to the action’s details.

  • Filter – The filter icon lets you choose the types of actions you want to include or exclude from the watchlist. There are currently four filter categories: Event Handlers, Action Types, Component Tags, and Action Names. Event Handlers are DOM events that are triggered on the window. These are usually pretty noisy and are therefore excluded by default. Action Types lets you choose between user-triggered and framework-triggered actions. Component Tags lets you choose which components to record actions for. Action Names lets you choose specific actions to record (like NOW_BUTTON#CLICKED).

Transactions

The “Transactions” tab records the transactions that happen on the page, as well as the chain of transactions that followed on the client.

Similar to the “Actions” tab, the “Transactions” tab has an option to filter down the transactions that are recorded. There are currently two filter categories: Event Types, and Component Tags. Event Types lets you choose the types of events that are recorded, such as HTTP events, client script executions, and dispatches. Component Tags lets you choose which components to record events for.

Logs

The “Logs” tab displays a component’s log messages and log info. It’s important to note that these are not server-side logs, nor are they console logs. This tab is mostly helpful for debugging custom components through log statements in the component code. It can also be used to debug errors when loading components on a page.

Another important note is that no logs will show up unless you specifically allow the logs of that type in the log settings.

Next UI Profiler

The “Next UI Profiler” tab lets you profile a Next Experience page to check its performance. You can do this one of two ways: starting a new manual recording, or recording a page load. A manual recording is ideal for recording a specific set of actions, while recording a page load is ideal for checking the performance of the initial load time.

Regardless of the type of recording you choose, you will have access to a timeline, a flame graph, and event data.

  • Timeline – The timeline shows the frequency of events over the course of the recording. You can manually trim the timeline to look at a specific sequence of events, or you can use the filter to determine which combination of component events to start and end the timeline at.

  • Flame Graph – The flame graph shows the total load time for each component on the page. If you click on a bar in the flame graph, it will show you which components made up the total load time for the component that you clicked on.

  • Event Data – There are four tabs that display event data: Summary, Events, Profile Metadata, and Performance Counters. Summary shows the total load time, as well as a graph depicting how many events of each type were triggered. Events shows a sortable, filterable list of all the events that were triggered during the recording. Profile Metadata shows information about when and where the recording occurred, including the Chrome and Next Experience Framework versions. As for Performance Counters, I’m not actually sure what gets recorded here. In all my testing and experimenting, the Performance Counters tab always said “No Metrics Available”. So your guess is as good as mine!

In addition to the timeline, flame graph, and event data, the Next UI Profiler also has the capability to compare two different recordings. As an example, let’s say that a workspace page is loading slowly on one instance but is loading fine on another instance. You can use the Next Experience Developer Tools to record the page load on the instance with the slow workspace, download the recording, upload the recording to the instance with the faster workspace, and compare the results. Here are some steps outlining the process:

  1. Record the page load on the instance with the slow workspace & download the recording

  1. Record the page load on the instance with the faster workspace
  2. Upload the recording from the slow workspace & click “Compare”

The comparison view shows the profile metadata and event count for each recording. Sorting and filtering the results in the comparison chart should help give an indicator into what is different between the two recordings and hopefully help single out the issue.

My Favorites

Now that we’ve gone through the general features of the extension, I want to highlight a few of my favorites:

  1. Next UI Inspector component properties – The ability to see all the available properties and property schemas of a component is very useful when doing more advanced work in UI Builder, especially when using data binding.
  2. Next UI Inspector component actions – Being able to see the actions dispatched by a component will be very helpful for debugging. If an action isn’t triggering the way you expect, try inspecting the component’s actions and see what is actually being sent.
  3. Next UI Profiler flame graph – Having a visual representation of component and page load time is very helpful in diagnosing poor performance. All it takes is a quick scroll to see which components are loading slowly.

Conclusion

Overall, I am very impressed with the Next Experience Developer Tools! I’m sure more features will be released as they get feedback about the extension, but even the set of features they have released so far are very extensive and useful. I can see this being a huge help to anyone configuring workspace experiences or building custom components with the Next Experience Framework. I am looking forward to using this more in my day-to-day life as a ServiceNow developer!