UI Builder - Events

[Chris Pearson]

Disclaimer: The ideas, thoughts, and opinions in this post reflect my own views and do not necessarily represent the views of my employer, Accenture. 

In previous blogs I've covered the basics of layouts, dragging in components, retrieving data from the DB and binding it to those components.

You now have a page which can display data. Great!

But we're not stopping there, this is an Experience after all. We need to make things happen at different times while users are interacting with the Experience. For that, we take advantage of Events. Events have been added to each component which align to that component's functionality. For example, a Button component has a 'Button clicked' event built into it. A Simple List component has all of the following events built into it: Row clicked, Scroll updated, Data fetch requested, Data fetch succeeded, Data fetch failed, and View all clicked. 

From each of these events you can configure your Experience to do any number of things. Here is an example of the options to choose from when a row on a list is clicked. We can link to a new destination (page), change URL parms, manage modals (pop-ups), work with page-level handlers, or refresh specific data brokers we have running on our page. The more you have built out your page with brokers, client scripts, or client states, the more options you have available to you for each event triggered. 

Let's go down the path of someone clicking on a row of a list and how we take them to a page which shows the details of that record.  

First, we need to have built at least the framework of the page to which we want to redirect the user. So we'll need a 'record' page in existence. Let's assume we have that in place and to make our page reusable for any record on any table, we set up that page with mandatory page properties of 'table' and 'sysId'. 

From our Event handler window we select 'Link to destination', then click the 'Select destination' button, expand our App routes section and choose the page we created...'Record'. Because this page has been set up with mandatory page properties, we now have two fields to fill out at a minimum, 'table' and 'sysId'.  

ServiceNow has done the hard work for us by ensuring the List component is pre-built with all of the functionality we would assume a List component would have so we can simply bind the table property to '@payload.table' which will be the table of our list's configuration. Similarly, we can bind the sysId property to '@payload.sys_id' which will be the sys_id of the record for the row we clicked, and then click OK to save. 

Now, when a user clicks a row from our list of records, they are taken to a new page in our Experience which shows the details of that record!