How to do this , reducing Client scripts, Is it good idea ?

Sironi
Kilo Sage

Hi All,

Kindly help me on my concern, 

if we have multiple OnChange client scripts on single field on same table , there Reducing all client scripts into single OnChange is Good Idea ?

if reducing  is Good Idea , then why ServiceNow OOB has multiple scripts on single field on same table ?  , they should have designed in Single -OnChange script . why they didn't design in single OnChange script ?

Supriya25_0-1753679910819.png

Sironi_0-1753680826250.png

Sironi_1-1753680890272.png

Sironi_2-1753681012766.png

 

Please share your opinions and suggestions on this.



4 ACCEPTED SOLUTIONS

Ankur Bawiskar
Tera Patron
Tera Patron

@Sironi 

yes it's recommended but sometimes each onChange is written to handle different use-case.

But if the script becomes too complex with multiple IF else then better to separate those out.

Developers might have created new onChange on state field without noticing there was already onChange.

If my response helped please mark it correct and close the thread so that it benefits future readers.

Regards,
Ankur
Certified Technical Architect  ||  9x ServiceNow MVP  ||  ServiceNow Community Leader

View solution in original post

Nikhil Bajaj9
Giga Sage

Hi @Sironi ,

 

Although there are multiple client scripts on same field but there requirements and codes are different. You can't put all conditions/requirement in one client script. It will be very messy to understand and very difficult to maintain code so code is always broken down into pieces (one requirement, one code) for better readability, maintenance.

I dont think clubbing multiple codes/requirements in one scrip tis possible and advisable.

 

If my answer helped you in anyways, please mark it solution accepted.

Regards,

Nikhil Bajaj

Please appreciate my efforts, help and support extended to you by clicking on – “Accept as Solution”; button under my answer. It will motivate me to help others as well.
Regards,
Nikhil Bajaj

View solution in original post

Mark Manders
Mega Patron

If you do everything with one client script, it will be very complex to add another requirement to it, because every single use case that is handled through that client script, will have to be tested again. 

It will be difficult to troubleshoot and when you are making Ajax calls it becomes impossible to follow. 

 

Breaking it down helps with making it understandable (the title of the client script already tells you what it does) and it is easily changed.

 

That being said: if it is handling the same use case, it should be in the same script. My experience is that often things are added instead of updated. Many 'developers' just add something to comply to certain requirements instead of checking what's already there. 

 

So you could probably combine some of those scripts, but make sure it stays easy to troubleshoot/read and also maintainable.


Please mark any helpful or correct solutions as such. That helps others find their solutions.
Mark

View solution in original post

Hi @Sironi ,

 

If we got such reuqirements which can't be clubbed together so definitely we need to create separate scripts, we dont have any choice. It will not result in any performance issue. Even if it willdo we have any other choice, no then go ahed. Only thing we can keep in mind to follow best practices while writing our code/scripts.

 

Regards,

Nikhil Bajaj

Please appreciate my efforts, help and support extended to you by clicking on – “Accept as Solution”; button under my answer. It will motivate me to help others as well.
Regards,
Nikhil Bajaj

View solution in original post

16 REPLIES 16

Syvo
Mega Guru

Hi,

I am currently dealing with this kind of issue. A number of different developpers added their own client scipts and UI policies on an already very complex onboarding HR Case. Now every time we deploy a new version with small adjustments there are side effects such as missing fields, or fields displayed and mandatory when they should not.

I think the right answer is somewhere in the middle: we should not have that many objects, but we don't want a single script to do everything neither.

I'll keep an eye on this discussion though in case someone has some interesting suggestions.

Hi @Syvo ,

 

Exactly any single approach is not good - Segregating a lot of code in different scripts or clubbing multiple scripts into one script. We should judge and see the feasibility based on requirements and complexity, what can be clubbed and what can't be. Code should be readbale and understandable. Question was to club all in one so i replied like its not very good but yes solution is somewhere in between based on feasibility.

 

Regards,

Nikhil Bajaj

Please appreciate my efforts, help and support extended to you by clicking on – “Accept as Solution”; button under my answer. It will motivate me to help others as well.
Regards,
Nikhil Bajaj

thanks for sharing your opinion

Hi @Sironi ,

 

Welcome and i like your gesture that you are thanking all who shared their experiences. It motivates all to help others as well on the community. Please close the thread by marking appropriate answer as - solution accepted. If you want you can mark more then one answer as solution accepted. 

 

Regards,

Nikhil Bajaj

Please appreciate my efforts, help and support extended to you by clicking on – “Accept as Solution”; button under my answer. It will motivate me to help others as well.
Regards,
Nikhil Bajaj

Hi @Nikhil Bajaj9 

Thanks for your valuable inputs . I got clear view on current issue which is best way . below one is my last concern.  it would be great if you can help with your inputs.

if we get 15 requirments on same field on same table does not match each other requirement  then so obviously we have to design 15 scripts, does it creates any performance issue ?