Introduction

If you've ever worked on a large CRM project or had to deal with a CRM 4 upgrade of any size you may quickly find yourself in a sea of JavaScript that can begin to look a little overwhelming. Personally I loathe most JavaScript that comes my way because you tend to get these 5 page long methods that do everything, all the field names are hard coded strings and option sets/form event mode constants are all numeric values so you can't just read the code and quickly understand what it is doing. To make matters worse JavaScript is not like coding in C# so there are so many more opportunities for things to go wrong. Since JavaScript is very loose and the tools available at the moment aren't very strong in design time error and dependency checking are not up to par with managed code it will pay big dividends to try and be a little stricter up front when it comes to writing your client side code and keeping those libraries organized.  

The following is my conceptual working model that I'm working on as I've had to deal with development issues during my travels. Mind you I have not yet had an opportunity to implement this in an actual project yet so let's just call this an philosophical discussion for now.
 
JavaScript Web Resource Functional Breakdown Structure
 
It is helpful to look at your JavaScript library from a top down hierarchical perspective. There is more investment up front in taking the time to organize this way because it requires more strategic thinking about the actual implementation but it pays dividend when the time comes to upgrade or maintain the solution code.
 
1 ->Organization -> 2) Entity -> 3) Form -> 4) Function Area

 


 
Splitting the JavaScript files down in this way has several advantages:
  1. Keeps the code organized by functional concern and helps to reduce code duplication.
     
  2. Splitting the code into files in this way allows for easier concurrent development in a multi-developer environment. When everything is in a few files then developers have to wait until the file is checked back in by someone else.
     
  3. Reduces conceptual complexity by breaking down the functionality by area of concern. How easy is to read a 2 mile long JavaScript file?
As you can imagine the premise with this structure is that any code that is applicable to all entities should be put into the organization level file. Any code that is specific to a particular entity is put into the entity specific file and so on. The break down structure is really more of an tactical ideal than "the way" to do it. I'm not saying break all files down to the absolute bottom. It just depends on the side the problem you are trying to solve. I know in certain situations for example on the opportunity entity that there can be so much code that it made sense to break down the code into the bottom most layer of functional area.
 
JavaScript Library Organization and Standards
 
C# coding standards versus JavaScript coding standards
 
It has been very tempting to just use C# coding standards when it comes to method and variable naming. For example in JavaScript you’re your method names are supposed to start in lower case letters whereas in C# method names begin with Upper case letters. Since we are dealing with JavaScript I would say it’s best to stick with JavaScript coding practice. It doesn’t help though that when you go to add an event to a form field that the event names are camel case such as OnChange versus onchange.
 
Use of JavaScript name spaces to encapsulate solution code
 
If you look at the CRM JavaScript object model you’ll notice that the root object Xrm is actually just a JavaScript namespace. Underneath Xrm you get down to the methods that Microsoft has created to obfuscate you away from the actually code implementation. I think that it would be helpful to do the same when writing code for a solution. Instead of just having a file with a bunch of methods in it why not organize it similar to how you would in C#. This also has the added advantage of giving you the ability to use Visual Studio’s intellisense.
 
Don’t hard code everything
 
JavaScript is a pain as it is since it doesn’t have the same compile time error checking as C#. So if you’ve ever come across a large library with field names hardcoded everywhere you know what I’m talking about. I believe in keeping the same standard for your JavaScript as your C# code. Hard coded field names, option set values and form event enumerations are not very friendly to the developer that has to come in behind you to make code changes. As it is called in Agile terminology this is what is referred to as “technical debt”. There is a mess on the floor in the kitchen. Everyone can see the mess but no one want to clean it up out of fear they may break something that “already works”. Just don’t make the mess in the first place and no one has to worry about it later.
 
Summary
 
JavaScript libraries in CRM can quickly become a beast to manage. While the amount of JavaScript necessary in solution for CRM 2011 is much less than it was in CRM 4 it can still be a force to be reckoned with and shouldn’t be taken lightly. As I continue down this path of JavaScript philosophy I’ll probably post a more detailed account of actually implementing this in practice.