Building strong functionality begins with writing high-quality code. Make your code manageable, efficient, and scalable from the early stages. This helps to ensure good performance, reduces the chances of problems, and simplifies the debugging process.
How should you write the code:
-
Easy to read.
-
Modular components.
-
Self-executing functions.
-
Avoiding pitfalls.
These 4 major practices help build both server-side as well as client-side functionality. Client Script in ServiceNow is a piece of JavaScript code which runs on the client, rather than the server. As mentioned above well-designed Client Scripts can reduce the amount of time it takes to complete the form and improve the user experience.
Client Scripts in ServiceNow apply to forms only except the onCellEdit Client Script.
ServiceNow also has one greater feature which helps build client-side logic ‘UI Policy’. Both UI policies and Client Scripts execute client-side logic and use the same API. To decide which client-side script to use, please go through documentation here.
Best practices to ensure while coding the Client Scripts:
-
Run Only Necessary Client Scripts
-
Enclose Code in Functions
-
Minimize Server Lookups
-
Practices to Avoid
Validating input from the user is an excellent use of Client Scripts. Validation improves the user experience because the user finds out if there are data issues before submitting the information.
The ability to set an order of execution, very similar to UI Policies gives us opportunity to select which Client Script should take a preference. Scripts are executed in order from low to high. A script with an Order value of 100 executes before a script with an Order value of 300.
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.
Example: -
-
Replace the GlideRecord and getReference with an asynchronous GlideAjax call.
-
The isLoading flag should be used at the beginning of any script which is not required to run when the form is loading.
-
Add newValue checks which prevents the script from running when the value is removed or blanked out.
Enclose Code in Functions
When code is not enclosed in a function, variables and other objects are available and shared to all other client-side scripts. If you're using the same variable names, it is possible they could collide. This can lead to unexpected consequences that are difficult to troubleshoot.
This solution is much safer because the scope of the variable state is limited to the onSubmit() function. Therefore, the state variable does not conflict with state variables in other client-side scripts.
Minimize Server Lookups
There are multiple methods to bring the server-side data on the client-side, but we will talk of only recommended ways rather than all.
Recommended: - g_scratchpad and asynchronous GlideAjax call.
Non-recommended: - GlideRecord and g_form.getReference()
The primary difference between these methods is that g_scratchpad is sent once when a form is loaded, whereas GlideAjax is dynamically triggered when the client requests information from the server. 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.
Learn more: - g_scratchpad, GlideAjax
Practices to Avoid
While scripting for Client-side Script / ServiceNow Client Script, there are two major practices to avoid which could impact more as compared to other practices:
-
DOM Manipulation
-
Global Client Scripts
DOM manipulation in JavaScript is the process of interacting with the DOM API to change or modify an HTML document that will be displayed in a web browser. By manipulating the DOM, we can create web applications that update the data in a web page without refreshing the page. The DOM stands for Document Object Model.
Avoid Document Object Model (DOM) manipulation if possible. It can cause a maintainability issue when browsers are updated. The only exception is when you oversee the DOM: in UI Pages, and the Service Portal. Instead, use the GlideForm API or consider a different approach for the solution.
A global client script is any client script where the selected Table is Global. Global client scripts have no table restrictions; therefore, they will load on every page in the system introducing browser load delay in the process.
As an alternative, and for a more modular and scalable approach, consider moving client scripts to a base table (such as Task [task] or Configuration Item [cmdb_ci]) that can be inherited for all the child/extending tables. This eliminates the system loading the scripts on every form in the UI - such as home pages or Service Catalog where they are rarely (if ever) needed.
Thank You!
Regards,
Kailash Bhange,
Rising 
