Last week, communication from Ninox to the HTML input element was established by inserting the ‘Slider Value’ Ninox field into the string being passed to the html() function. This week, communication in the other direction, from the HTML slider to the ‘Slider Value’ field in Ninox, will be configured.
Since the HTML cannot directly communicate with Ninox through the browser, we will do this by way of the Ninox API. The Ninox API allows us to make a request to the server to do anything you might do in the Ninox application. View all the records in a table, create a new record with specified field values, update the fields of an existing record, delete a record etc. If you have not already, I recommend reading David’s article on API basics before proceeding. It will also be useful to take a look at the Ninox REST API documentation.
In order to proceed you will need to get access to one of your Ninox API keys. In this article the API key will be referenced from a hidden text field in the Formula Code for security.
The end goal is to update the value of the ‘Slider Value’ field via API when the user changes the value of the slider. This means we will need to use our good old friend from PART 1, events.
In PART 1 the oninput event was used to update the number above the slider whenever the user changes the value of the slider. This is great for real-time display, but the oninput event fires every time the slightest movement is made to the slider, and sending out API requests at such a high frequency would cause issues. All that is needed is to update the value when the user lifts their finger off the mouse when they drop the slider at the desired value. Thankfully, there is another event, onchange which fires exactly at this time. Another function can be inserted into the script tag and called from an ‘onchange’ attribute in the input element.
html("" + text('Slider Value') + "")
In the HTML above, the updateNinox() function is called from the ‘onchange’ attribute of the slider. This function has the ‘async’ keyword to enable it to wait for the response from the Ninox server without stopping other processes.
In updateNinox(), we start by disabling the slider while the request is being sent, by setting its disabled attribute to true. The next section gets all of the information needed to locate the current record. Because API requests can be sent from anywhere, they require a complete address to the data that is being updated. For Ninox, we need the team ID, database ID, table ID, and record ID to locate the record we are currently in. This information is available in the url of the current page, and could be hard coded into the HTML, but getting them from the url each time makes the code more transportable to other tables, databases, or teams.
The whole url is accessed with location.href, and stored in the currentUrl variable. This could also be done with the new urlOf(this) ninox function, and inserted into the HTML string. The team ID, database ID, and table id are all extracted from currentUrl by splitting the url with the split() string method. The record Id is inserted from Ninox, since it is a little harder to extract it from the url (it is concatenated to the table ID after ‘/node/’ in the url).
Once the necessary information is extracted from the current url, the url of the API request is constructed using that information, and stored in the ‘url’ variable. Then the data to send to the Ninox API is stored in ‘data’. Take a look at the Ninox REST API Documentation to see how to format the body of the request, and the url of the request.
Once the request is sent, the “await” keyword in front of fetch ensures that the function halts until the response is received from the server before executing the next line of code. Once the fetch() call returns the Ninox server’s response, the slider is re-enabled.
Here is the final slider with two way communication: