The following functions and widgets support writing custom JavaScript expressions in a mashup:

You can use the TW.log() function to log debug, error, warning, and information messages related to expression in a mashup. Log messages are displayed in the mashup log dialog at run time. For example:

Opening mashups that contain a large numbers of expression logging statements impacts the mashup performance significantly. If you are using a large number of log statements in your mashups, we recommend that you avoid using them in a live production environment. You can use log statements while developing and testing a mashup, .but you should convert them into comment or remove them from the code before deploying the mashup to a production environment.

After designing a mashup that contains expressions, check the debug information dialog box at run time. You can use this feature to trace the execution of your mashup, which helps you identity logic issues, such as circular bindings and infinite loops in your design or implementation. To view debug information for a mashup, click Show/Hide Debug Info on the run-time toolbar.

When working with JSON data in an expression, avoid using the JSON.parse() method to parse and convert JSON from a string. You can access JSON objects within parameters that are set to a JSON base type directly.

In previous versions of ThingWorx, setTimeout is not supported in function expressions. In ThingWorx 9.6 or later, you can execute up to 10 expressions that contain a TW.setTimeout function at the same time. You can define a single setTimeout function in each expression function. Any code that is added before or after the setTimeout function in the expression is not executed. The maximum time out value that you can set for a function is limited to 10 seconds. When the defined value exceeds this limit, the function value is automatically set to 10 seconds and a TW.log.warn message is displayed in the mashup logs at runtime.

The name and value pairs stored in the window.sessionStorage object are available for the duration of the browser session only. Possibility for race conditions can occur because secure expressions run asynchronously. For example an expression can update the session storage properties and another may run before getting the updated values. To reduce race conditions and ensure that session storage updates are available when another expression starts to run, you should chain the expressions using a Changed event.