What is a Client Script?
In ServiceNow, a Client Script is a JavaScript code snippet that executes on the Client-Side, directly within the user's web browser instead of the server. These scripts serve diverse purposes, including data validation to ensure the user's input is valid before form submission, preventing errors, and maintaining data integrity. Additionally, Client Scripts are utilized for operations such as hiding fields. They are triggered by specific events occurring on a form, such as:
onLoad: When the form first loads.onSubmit: When the user tries to submit the form.onChange: When the value of a particular field changes.onCellEdit: When a user edits a value in a specific cell of a table field.
Why is this an issue?
Forms play a crucial role in navigating ServiceNow, as they are present at various levels throughout the platform and when interacting with any edition or reading a record.
Given their significance, a well-designed and developed Client Script is essential when impacting a form to ensure optimal user experience without compromising loading speed. Incorrectly invoking server calls, especially in the case of onLoad type forms, can lead to significant performance issues. Three types of queries are particularly detrimental and can result in a bad user experience:
GlideRecord: Initiating a GlideRecord query on the client side may lead to unnecessary server requests, fetching more information than actually required for your script.
GlideAjax: While this API is at times a suitable alternative, there exists a more efficient and healthier approach for obtaining values directly from the server in
onLoadclient scripts.g_form.getReference(): In Reference fields
getReference()involves retrieving all fields from a referenced table in a record, causing the server to provide more information than necessary.
For instance, in the case of an onLoad type, it implies that each time a user accesses that form, the associated client script will run. Therefore, if there are multiple or inefficient server queries within the script, it directly affects the user's experience and usability in your instance.
How do I fix it?
The most effective approach is to utilize the g_scratchpad object. The g_scratchpad object serves as a bridge, transferring information from the server to the client side. This is particularly useful when the client needs information that is not readily available on the form.
When you are aware of the information the client requires from the server before the form is loaded, a display business rule can be employed to generate g_scratchpad properties.
Consider a scenario where, upon opening an incident, the client requires the following information:
- The name of the caller's manager.
- The value associated with a property named
organization.incident.code.
To retrieve the information required by the client, you can use the following code:
Within a display business rule:
1 2 3// Populating g_scratchpad with manager name and organization code g_scratchpad.managerName = current.caller_id.manager.getDisplayValue(); g_scratchpad.orgCode = gs.getProperty("organization.incident.code");
And in your client script:
1 2 3 4// Checking if organization code property exists and displaying an alert accordingly if (g_scratchpad.orgCode) alert("You manager name is " + g_scratchpad.managerName); else alert("Organization code property is missing for your instance!");
Another common practice that is detrimental to performance involves obtaining information from the server on the client side. This implies placing the desired field in a form and subsequently concealing it using a UI policy.