Customizations - Dev Console vs. CustomSpace

Brad_McKenna

Howdie All,

I am seeking some guidance on understanding why I am having an issue and how to resolve it. I often obtain items or ideas from here, test them out in the Dev Console of the a browser (IE 11 or Chrome) and the customizations work without issue then fail to work as expected when added to CustomSpace.

I try one of two methods, adding code directly to Custom.js, or create a new file with the custom code and call/load it via Custom.js.

Example1: http://blog.coretech.dk/mme/customization-tips-to-the-cireson-portal/

I have added a new field to the Change Request form that is to be hidden if the Category for the template does not equal Minor. If the Category = Minor, then I attempt to add the attribute to require the field, then change the text and coloring of the label.

This code is loaded via loadscript() in Custom.js

I then have this code added to Custom.js to handle new CR's created

The else content in both is the values that I have tried to add, with the expectation that they will require the field and change the text when the condition is met, however this is not happening.

Example 2:

As referenced in this thread by Tom_Hendricks https://community.cireson.com/discussion/comment/7942#Comment_7942 to hide fields. These work flawlessly when executed via the Dev Console, but not once added to CustomSpace via one of the two methods above.

For my testing I try to run in Incognito or using Ctrl + F5 to clear the cache and perform the hard reload with the expectation that the code would run successfully.

I have experienced these issues on 7.6 and 8.0, and thinking it must be something I am doing and not a bug with the portal.

Any and all help is greatly appreciated.

Nicholas_Velich

Hi Brad,

The problem here is the browser does a lot of things on page load, and it does them very quickly to the point its unnoticeable. When the webpage loads, a lot of content is processing and being added within milliseconds behind the scenes (technically right in front of you ). When you have code run in the browser's Dev console, the majority of the web page is already finished loading, so code works as expected; however, when you put code in custom.js (whether direct or via external file), it is not guaranteed to be executed when you're ready for it.

In your example of the "Hide Activity Fields," you are actually hiding the activity fields before they exist. It is simple to slowdown code execution to see this point in action. First, wrap your code in a setTimeout() function just to give it a delay before execution. You should see your code execute in the same way as the Dev console if you give it a 2-3 second delay. Example of setTimeout here: https://www.w3schools.com/jsref/met_win_settimeout.asp 

While delays are great to prove the point, they are unreliable in practice because we cannot predict how quickly a page will load every time-- too fast and we execute our code before intended, too slow and the user might notice the changes. A better approach would be to use something called a "mutation observer." We have a few examples of this floating around, but I'll see if I can dig one up for you.

Thanks,
Nick

Nicholas_Velich

Here is an example of the HideActivityFields code that uses a mutation observer. This approach is essentially saying, "execute the hide activity field code when we know that the activity field exists," rather than "hide the activity fields ASAP" (your example), or "hide these activity fields after a 3 second delay" (timeout example).

Nicholas_Velich

Hi Brad,

The problem here is the browser does a lot of things on page load, and it does them very quickly to the point its unnoticeable. When the webpage loads, a lot of content is processing and being added within milliseconds behind the scenes (technically right in front of you ). When you have code run in the browser's Dev console, the majority of the web page is already finished loading, so code works as expected; however, when you put code in custom.js (whether direct or via external file), it is not guaranteed to be executed when you're ready for it.

In your example of the "Hide Activity Fields," you are actually hiding the activity fields before they exist. It is simple to slowdown code execution to see this point in action. First, wrap your code in a setTimeout() function just to give it a delay before execution. You should see your code execute in the same way as the Dev console if you give it a 2-3 second delay. Example of setTimeout here: https://www.w3schools.com/jsref/met_win_settimeout.asp 

While delays are great to prove the point, they are unreliable in practice because we cannot predict how quickly a page will load every time-- too fast and we execute our code before intended, too slow and the user might notice the changes. A better approach would be to use something called a "mutation observer." We have a few examples of this floating around, but I'll see if I can dig one up for you.

Thanks,
Nick

Nicholas_Velich

Here is an example of the HideActivityFields code that uses a mutation observer. This approach is essentially saying, "execute the hide activity field code when we know that the activity field exists," rather than "hide the activity fields ASAP" (your example), or "hide these activity fields after a 3 second delay" (timeout example).

Brad_McKenna

Thank you for the quick and detailed reply @Nicholas_Velich.

I forgot all about the mutation observer and the need for its usage.  Like you stated with timeout, a bit unreliable as we experienced with a implementation of mine in attempt to hurdle templates. 

Nicholas_Velich

My pleasure-- hope it helped!