No secret I love Javascript.
It’s messy to the right point, it can be quick and dirty, it can be elegant, it can be wathever you are: your Javascript code can be a mirror of your personality.
And what’s better that putting together 2 things I like the most?
Yes, I’m talking about Salesforce and Javascript.
Javascript is the core of the new Lightning framework but since the birth of S-Controls (now deprecated) and Visualforce it’s been an importanto tool to expand the standard Salesforce platform.
What do you have to know before starting your Javascript journey with Visualforce?
Use zipped static resources for your scripts
Put all your JS files into a zipped static resource, this way you have aboslute control over the place where files are stored and have no problem finding them.
Use the apex:includeScript
If you use the HTML script tag the resources can be loaded more than once and this can lead to unexpected errors.
Think you are using jQuery and Bootstrap and your page loads them in sequence.
In the same Visualforce you also use a custom Visualforce component which loads jQuery itself: what’s the outcome? Bootstrap is simply erased from jQuery plugins.
The apex:includeScript component loads all the JS files only once, avoiding this kind of conflicts.
Use only one version per library
This is the same scenario of the previous paragraph.
If you load, e.g., jQuery 2 in one point and jQuery 3 on another place, this could lead to conflicts and strange behavior.
Keeping you library version on a static resouces allow you to get the right library version across all Visualforce page and components.
Use jQuery as much as you can
You’ll be using Javascript because you’ll want to create a slick, modern and responsive UI, so why reinvent the wheel?
Some good programmers still lack in jQuery knowledge, if you are one of them keep some time to study the bases of the library and I assure you won’t regret it…and you can be sure you’ll have really few problems for compatibility on different browsers.
Give all your components an ID / class name
When you develop a new Visualforce page take few minutes more that necessary to give all your components a recognizable html ID.
<page id="thePage">
<pageBlock id="mainPB">
<apex:pageBlockSection id="customerDataPBS" rendered="{!showCustomerData}">
<apex:pageBlockSectionItem id="csDataNamePBSI">
<apex:outputLabel id="csDataNameLBL">Name</apex:outputLabel>
<apex:outputPanel id="csDataNameVAL">
<apex:inputField id="csDataNameINP" value="{!account.Name}" />
<apex:commandButton id="refreshCsNameBTN"
value="Refresh Data..."
action="{!refreshAccountName}"
rerender="csDataNameVAL" />
</apex:outputPanel>
</apex:pageBlockSectionItem>
</apex:pageBlockSection>
</pageBlock>
</page>
This will ease your life if in the near future you decide to use Javascript to access the page’s markup.
Remember that IDs are automatically calculate by the Visualforce render engine, so if you want the exact ID you can use the $Component global variable, so if you want to access the apex:inputField on the previous code:
document.getElementById("{!$Component.thePage.mainPB.customerDataPBS.csDataNamePBSI.csDataNameINP}");
But I recommend not to use this way.
This is not incorrect but as you continue your Visualforce development (sometimes the customers you work with don’t know what they actually want till they want it!) you can change the UI, moving sections on the page, so the ID chain can change over time.
That’s why you can use the “ends with” operator with jQuery to get an HTML component:
var inputField = $('[id$="csDataNameINP"]');
That is easier. The only thing is that you must be sure that you only have one and only one component with that ID.
Sometimes I use class names rather that ID, so for example:
<apex:inputField class="csDataNameINP" value="{!account.Name}" />
This way I don’t care about ID generation and go directly with searching for a specific class name.
var inputField = $('.csDataNameINP');
That is even clearer (this is something I usually do and I like the syntax but it is not a best practice).
