01/06/2020
By Nikhil Rajendran | Reading time 5 mins
By Nikhil Rajendran | Reading time 5 mins
In any Microsoft Dynamics CRM instance, there are functionalities requested by the stakeholders which go beyond the functionalities offered by the Out-of-the-Box CRM instance. To deliver these functionalities we often need to write Java.
As a developer, if you have coded long enough on a project and know the CRM instance well, it is very easy to get complacent. It could also be that you’re tired. You need to just get the functionality out of the way and go home.
It is during these times that we just throw the best practices out of the window. When we do that, it will eventually come back to make you realize your folly in some way or the other. I have experienced this! So it is better to just get it right the first time. JavaScript is fairly unreliable. Especially when we have promoted new code in the CRM instance. It does not work for a few users because of cache issue. Instructing the users to clear cache can be frustrating especially when the users are not tech-savvy.
Let us look at some of the best practices while writing JavaScript in Dynamics CRM.
I personally avoid JavaScript minifiers as much as possible. In a bid to reduce the size of the libraries developers use minifiers when they feel it gets too large. While minifiers has its advantages, it also comes with a few negative factors as well.
Readability is a major issue. Once a code is minified it looks like one major paragraph. It becomes very difficult to debug issues in the code as well. The non-minified version of the code also needs to be maintained in a Source Control or at least in the Web Resources of the organization.
This will help the developer to debug issues.
Each entity should have 2 JavaScript libraries. One for the form and the other for the ribbon.
Readability is a major advantage. If a developer needs to address an issue related to a button not appearing, he does not need to go through a massive library that contains all functions.
He can look at only the ribbon library and debug the issue. Have the names of the button in the function name. For example,
function button1DisplayRules()
{
//code goes here.
}
As the name indicates, the library contains the display rules of button 1.
If a form is taking too long to load, it probably means your JavaScript code is expensive. It would be a good idea at that time to use some performance analyzer tools to find out what is expensive. Fiddler is a great tool. To perform some small initial analysis, we can use some of the browser tools to analyze the live run time data. To do so,
It is not necessary that these need to be done only when the performance is going down. We can always be proactive- do this every before new functionality is introduced to Production to make sure that it is not expensive.
Talk to us if you want to get more out of your CRM solution.
Nikhil has been with AhaApps since 2017 as a Microsoft Dynamics CRM Developer. He is a driven CRM expert who is ready to fight off the challenges in the Dynamics world with his technical know-how and prowess. He is a sports enthusiast and loves to play tennis when he gets time. He is also a voracious reader and enjoys reading philosophical books.
There are times when you just become too complacent and throw best practices out of the window. Bad idea!