User Review
( votes)In any Microsoft Dynamics CRM instance, there are functionalities requested by the clients that 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.
And it is precisely during such times that the best practices are thrown 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 a 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.
Keep your libraries short and simple:
A general rule I like to follow is to try to limit the use of JavaScript as much as possible. I try to use JavaScript only for Data Validation, hiding/showing fields, small error messages.
Keep the libraries short and simple. It will increase performance and improve maintainability.
The libraries must be readable for the next developer. Ensure that there are sufficient comments in the code. Since JavaScript is mainly used for Data Validation, it can be easy for the next developer to get confused about why the logic is written the way it is. Comments can be very useful in those scenarios.
Try to limit the number of JavaScript libraries which are on a form. The reason is every time a form loads, the libraries are loaded. Too many libraries on a form can reduce performance.
JavaScript Minifiers:
I avoid JavaScript minifiers to a certain extent. In a bid to reduce the size of the libraries, developers use minifiers when they feel it gets too large. While minifiers has its benefits, it also comes with a few disadvantages as well.
Readability is a big issue. Once a code is minified it looks like one major paragraph. It becomes quite 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 helps the developer to debug issues.
Keep separate libraries for the form and ribbon:
Each entity needs to have 2 JavaScript libraries. One for the form and the other one for the ribbon.
Readability is a major advantage. If a developer needs to address an issue related to a button not appearing, he doesn’t 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.
Performance Analyzer tools:
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,
- Open the form which needs to be analyzed
- Control + Shift + Q
- Click the enable button
- Reload the form
- Hit Control + Shift + Q again
It is not necessary that these have to be done only when the performance is going down. One can be always proactive. This can be done 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.
Download our eBook “15 Questions to Identify the Gaps in Your CRM”
