JavaScript Evaluation

Internal allows for JavaScript evaluation (JS Eval) in various parts of the application.

Where to Use JS Eval in Internal

So, where do we make use of the power inherent in JavaScript evaluation in the confines of Internal?

For starters, we currently only support the use of JS Eval inside of template inputs, the function editor's URL parameters, header sections, and data transformer, and within the confines of template literals. This means that anything that you evaluate within the template input fields will be returned as a string for form or component input. Beyond that, the world is, as they say, your oyster. You can be as fancy as you like. Here are a few examples of ways in which you could make use of JS Eval in internal.

In the App Builder

Look for the input field editor in the righthand side of the App Builder. Inside, depending on the selected component, you'll see input configuration fields which allow for the use of JS Templates. Below is a list of some of the things that you can do with JS Eval in the App Builder.

Mathematical Expression

You can use the baked-in JS Math library, or run basic mathematical operations.

Six is added to six in a template literal
Euler's number is produced using the baked-in JavaScript Math library

Anonymous Functions

You can set variables and execute anonymous functions within the template input field.

Note: Functions assigned a variable (e.g. var foo = function((){YOUR FUNCTION}); foo(); ) will not evaluate and will return nothing in the published Space.

An anonymous function with variables (lets) and a mathematical evaluation returned in a template literal. This one returns the string "12"

Text concatenation with the string literal produced by the template literal mathematical evaluation inside of the ${ }. This one returns the string: "THIS STAYS TEXT 12"
Interpolation of Space-wide data into anonymous function and then concatenated by evaluation returning a template literal. This might read "Admin is wonderful" in its associated space.


Newlines inside of the template input translate into newlines in the published view.

Adding a newline to the template literal outside of an interpolated value will result in a newline in the published Space
A wild newline appears!

Published vs. Unpublished Views of Template Literals

The App Builder view and the published view for strings created in the template input field are drastically different; The published view contains the final string, and the App Builder view contains the text of the script itself.

The unpublished view of a template literal will show the entire script and any values associated
Things get considerably more attractive when published in a Space

Real-world Use-cases

Above are demonstrations of the basic capabilities of the template literal input field. Most of the applications of these would be for transforming data from the output of one component to the input of another, like a form.

For example:

  • Render conditional data based on multiple fields:
  • Currency conversion (USD -> Euro, rounding to 2 decimal places) -- and using our Function Component for a headless function call to a data provider:
  • Filter and map data:
  • Add fallback values:

In this case, the first template is for the Name (per option), where a data source has returned an array that returns an ID and an abbreviation for a country name, and the proper noun form of the name needs to be presented in the dropdown; the comma then shows the value for the input that will be sent to the function.

  • Evaluating data from different columns of a table and interpolating them into a single string for consumption in a form
  • Calculating taxes for invoices
  • Calculating days-since a ticket was opened in a trouble ticket database
  • Return a table full of customer IDs and map them to a single text output for insertion into a form

Components that Support JS Template Literals

Internal has created a way in which to surface Space-wide data for interpolation with JavaScript template literals. Currently, you can find these special input fields in the following locations:

Note: pre-configured inputs (e.g. Date/Time pickers) do not allow for template literals.

There are many potential use-cases, but the primary thing to take away from this should be that anything that can be done in a JavaScript template literal, can be done within the template input field in Internal. For simplicity's sake, just assume that the template literal input field is two back-ticks on either side of whatever you enter into it.

How To Use Template Literals to Interpolate Your Data

With each of the above-linked components and inputs, you will see a link beneath the template input field that looks like this:

A link labeled "Insert a variable" appears beneath the template input field

Clicking the link will result in a cascading selector that allows you to select from any data that is currently available within your Space. In the following example, we select the data from the column "name" from the selected table row in the table named "Dailies".

Cascading selector expanded as follows: Dailies > Selected Row > data and an arrow pointed to the "name" selector

Once you've selected your data from the cascade, it will display in the template input field as a JavaScript template literal.

The template input field with a new value `${}`

These template literals follow the same rules that govern vanilla JavaScript's function of the same name. This means that you can combine them into strings using plain text:

Three different data points represented as template literals are interspersed with plain text

In The Function Editor

The function editor contains a few places where JS Eval can take place. They are:

JS Template Literals being used as URL Parameter variables in the Configuration of an HTTP function
The Template Literal maps 1-to-1 with the parameter input for the function and can be sent to the function via a component, input, or in the test runner shown at the bottom of this image
  • In the data and meta data transformer (under the "Transform" tab in the Function Editor):
Snippet of a transformer using JS Eval to transform data (and metadata) into a more easily-read state.
  • In the Headers section of the "Configure" tab of the Function Editor in an HTTP function:
The Headers section here uses a Template Literal as a variable for an auth token
  • In the body of an HTTP Form:
Here, the Body of an HTTP request uses Template Literals to pass Key/Value pair in a Form body to an API endpoint

Debugging Your Templates

In the best of times, things don't always go the way that you'd expect. In the event that that should occur while creating your template (be it a script or an interpolated bit of data from your app), we've logged a whole lot of the actions taking place during the evaluation of the template input and dropped them into the JS console. Here's a primer in case you're new to all of this.

Something to note: we currently log an error when an evaluation fails, this includes when a binding hasn't been fulfilled for any reason (this can include a slow return from an API, or that the data is missing entirely). As such, you will likely see a lot of errors in the browser console. You can safely ignore any of them that stop repeating after data loads in the DOM.