Client scripts best practices
This article is based on the ServiceNow documentation article. See the original article on the ServiceNow doc site: Client Scripting Practices to Avoid.
A client script is JavaScript code which runs on the client, rather than the server. Well-designed client scripts can reduce the amount of time it takes to complete a form and improve the user experience. However, improperly implemented client scripts can significantly slow down form load times. Follow these best practices to ensure Client Scripts work efficiently.
Wrap code in functions
Enclose the code in a client script inside a function.
Client scripts without a function cause issues with variable scope. When code is not enclosed in a function, variables and other objects are available and shared to all other client-side scripts. If you are using the same variable names, it is possible that they could collide. This can lead to unexpected consequences that are difficult to troubleshoot.
Run only necessary client scripts
Client Scripts have no condition field. This means onLoad() and onChange() scripts run in their entirety every time the appropriate form is loaded. To avoid running time-consuming scripts unnecessarily, make sure client scripts perform only necessary tasks.
The following steps provide examples showing how to prevent the client script from running unnecessary code:
General cleanup
Look for performance optimizations. For example, the getReference(), or GlideRecord lookup can be replaced with an asynchronous GlideAjax call.
The isLoading flag is the simplest way to prevent unnecessary code from taking up browser time. The isLoading flag should be used at the beginning of any script which is not required to run when the form is loading. There is no need to run this script on a form load because the logic would have already run when the field was last changed. Adding the isLoading check to the script prevents it from doing a cmdb_ci lookup on every form load.
Keep the newValue check
The newValue check tells scripts to continue only if there is a valid value in the relevant field. This prevents the scripts from running when the field value is removed or blanked out. This also ensures that there will always be a valid value available when the rest of the script runs.
Add the newValue != oldValue check
To have the script react to a value which changes after the form loads, use the newValue != oldValue check.
Bury the GlideAjax call
The GlideAjax call can be buried a few levels deeper by rearranging the script to check as many things available to the client as possible before running the server calls. The script checks the assignment before executing the GlideAjax call. This prevents the server lookup when the assignment_group field is already set.
Avoid using GlideRecord queries in client side scripts
Client scripting uses either data available on the client or data retrieved from the server. Use client data as much as possible to eliminate the need for time-consuming server lookups. The top ways to get information from the server are g_scratchpad, and asynchronous GlideAjax lookup.
The primary difference between these methods is that g_scratchpad is sent once when a form is loaded (information is pushed from the server to the client), whereas GlideAjax is dynamically triggered when the client requests information from the server.
Other methods, GlideRecord and g_form.getReference() are also available for retrieving server information. However, these methods are no longer recommended due to their performance impact. Both methods retrieve all fields in the requested GlideRecord when most cases only require one field.
Avoid using synchronous AJAX methods in client side scripts
Synchronous AJAX methods (e.g., g_form.getReference, getXMLWait) will cause the user interface to freeze while the call is being completed, resulting in poor user experience. Use the asynchronous glideAjax.getXML() method instead.
