Accueil > Conseils > From Visualforce to Lightning Development

From Visualforce to Lightning Development

 11 minutes de lecture


mars 20, 2017


Or how to transition from back-end to front-end development

In 2015, Salesforce unveiled #Lightning Experience, a whole new UI for the Platform. Not only was it a visual change, but also a complete revamp of the technology behind it.

Whereas Salesforce Classic used a page-centric model, reloading the entire page whenever you clicked on a link, Lightning Experience uses an app-centric model (like Gmail for instance): The app will first load, and then will only need to call the server for lightweight data, refreshing only parts of the screen and thus speeding up navigation.

On a developer’s perspective, Lightning Experience makes use of the Lightning Component framework which is a complete new development experience for Salesforce developers.

Let’s have a look to a few tips to start Lightning Components development !

Learn JavaScript

With Visualforce, it’s possible to develop an entire application without writing any line of HTML, JavaScript or CSS. Some tags like <apex:pageBlock/> ensure that your application will render the same way as standard Salesforce pages, while some others like <apex:actionSupport/> with rerender will let you refresh a part of your page without any AJAX knowledge.

Lightning Components on the other hands are heavily based on JavaScript. This is great because lots of web developers will be able to start developing on the Salesforce Platform very quickly. However, if you’ve been an Apex/Visualforce developers for years mostly relying on apex tags, this may be a little bit more difficult.

Switching to Apex is pretty straightforward if you come from another Object-Oriented language like JAVA or .NET. Switching to JavaScript is a bit different and you may want to take some time learning the specificities of the language.

I won’t cover everything here as this is not the topic of this post, but some differences include:

  • A variable can be undefined or null, and it’s not the same thing
  • JavaScript is case sensitive, so myVar and myvar are 2 different variables
  • If you don’t declare one variable, JavaScript will do it for you. This may seems sweet at first, but it’s not if you combine it with case sensitivity. You may end up creating a second variable by mistake if you do a typo. The following code sample will create 2 variables:
var myVariable = 0;
myvariable = 1;
console.log(myVariable); // --> 0
console.log(myvariable); // --> 1

One good news, LockerService will prevent this from happening, throwing a error if a variable isn’t declared.

You’ll still need to be careful though, because this will still remain an issue while accessing properties. Let’s say in your JS Controller you are iterating through a list of objects, the code used to access a field will be case sensitive too. So if you have a field named “MyField__c”:

for(var i=0; i<listOfRecords.length; i++) {
    // --> This will work
    // --> Lower case typo in the first letter of the field's name
    // This will not crash but return undefined

As this is not crashing, you may not see it immediately and this could lead to strange and difficult to debug behaviors.

On the variable declaration topic, you may also want to have a deeper look to scoping and hoisting.

  • Everything is an object, including functions. This means that you can create a variable and later…execute it ! Something like this:
var myFunction;
myFunction = function(){
    alert("Hello World");

  • JavaScript is a loosely typed language, so you can assign any type to a variable, and change it on the fly:
var myVariable = 0;
console.log(typeof myVariable); // --> number
myVariable = "1";
console.log(typeof myVariable); // --> string

If this can be powerful, this can also be dangerous if you’re not careful enough. For instance regarding the previous function myFunction, you can assign another type to it:

myFunction = “I changed my mind, I’m just text.”;

Calling myFunction in this case will just crash your application:

  • During comparison, JavaScript will try to cast values to see if they match. As a result, all these comparisons will evaluate to true:
var myNumber = 0;
myString = “0”;
myBoolean = false;
console.log(myNumber == myString);  // --> true
console.log(myNumber == myBoolean); // --> true
console.log(myString == myBoolean); // --> true

To avoid this, use the triple equal sign, which will prevent automatic casting: myNumber === myString will return false. You can find more on comparison operators here.

There are lots of other things to learn and be aware of about JavaScript, like automatic semicolon insertion, that’s why I recommend taking the time to learn fully JavaScript.

The web is full of JavaScript resources, here a few I like:

More specifically, Dan Appleman has a great JavaScript course on Pluralsight targeted for Salesforce developers:

Use Lightning Experience

Most of the time, you’ll develop components for Lightning Experience. You’ll need to use the new Salesforce UI to understand how everything behave, because you certainly don’t want to offer your users a UX that is completely different from the rest of Salesforce.

While developing my first Lightning Components, I took a lot of time asking myself how things were done in Lightning Experience, and having a look to simple generic functionalities like:

  • How does pagination works on lists ? (hint: there is no pagination)
  • How should I display notification messages ?
  • Should I display a modal or navigate to a new page ?
  • Wait, and what about notifications when I’m in a modal (like errors) ?

This will help you create components that have a consistent UI and UX with Salesforce Lightning Experience. Moreover, while in Salesforce, make use of available Salesforce events instead of creating things from scratch.

For instance, notification messages are displayed this way:

Some recommandations:

  • If you’re on Lightning Experience, don’t recreate it from scratch. You’re not in Salesforce Classic anymore, Lightning is an application that gives you events you can leverage. In this case, firing force:showToast will do the job for you:
var toastEvent = $A.get(“e.force:showToast”);
    “message”: “Opportunity \”Awesome Opportunity!\” was saved.”,
    “type”: “success”
  • If you need to recreate a component (because it doesn’t exists, or you’re running your component outside of Lightning Experience), try to use the Lightning Design System. For instance for the notification shown above, you can use the Toast component.

Don’t forget it’s a component framework

Make use of the framework

Don’t stick with what you know from web development and try to add libraries like jQuery right away ! Lightning provides you with out of the box functions that are optimized for the framework, so use them. For instance, prefer using aura:id and component.find("v.myId") instead of document.getElementById("myId") or jQuery’s $("myId"). You can find all the documentation in the Reference Doc App.

Don’t reinvent the wheel

Salesforce is providing Lightning Base Components, so try to use them instead of creating your own components. Make use of the Framework functions and events. Also, the Salesforce Community is doing a great job in building free and open source components, so make us of them.If you haven’t already, you should have a look to Appiphony’s open source Strike components, as they’ve made an awesome job !

Think your components to be generic…

That may seems obvious, but one important part of the Lightning framework is the notion of components. You’ll want to create your components in a reusable way, so that another developer could use it later in the future. For instance, you don’t want every developer to create it’s own modal component, or hardcode modal’s content inside the modal. Think that this content could be used elsewhere, and make it a component.

…but not to much

If in theory having lots of generic and reusable components is the best, don’t forget that you may not need or have the time to do it.

For instance, let’s say you want to display an object’s fields on a component. Hardcoding them doesn’t look like a good practice, and having an attribute with the list of fields to display seems easy to do but:

  • Don’t forget that Lightning Components don’t enforce Field Level Security, so you need to do it.
  • Filtering a query based on a predefined field is easy, doing it on any field take more time. Is it a text field ? Date ? Boolean ? Is there multiple values ?
  • You’ll need to think of all use cases. For instance, your component is working when querying a few fields. Did you set a limit ? Is it working with relationships ? One level ? Two levels ?
  • Maybe making a generic component will need to add some more logic. This may impact performances so be sure to take the time needed to test everything.

So building a generic and reusable Lightning Component is great, but if you’re new to the framework, don’t underestimate the time you need to build it. This means more code, more testing, both on the functionalities and on performances. And may be useless if your component is too specific.

Test often

I mean, really. Visualforce is a mature framework, but Lightning Components still have some glitches that could drive you crazy. You really don’t want to code for a long time, and when you try it just see your whole app crashing with a generic error message like this:

Testing often will help you find what part of the application you’ve changed recently, and thus find faster what the issue is. There are a few best practices though.

Test with LockerService

LockerService will be mandatory in June 2017, so you certainly don’t want your components to break once it’s activated. Moreover, LockerService will help you avoiding errors in your code by enforcing strict mode.

Activate Debug Mode

In your development environment, enable Lightning Components Debug Mode. Your code won’t be minified and will be easier to read and debug. Don’t active it in Production though as this has an impact on performances.

Use Lightning CLI

Currently, linting is not part of the platform. This means that if you’re missing/adding something, like a comma or a curly bracket, your code will just save. Unfortunately, launching your app may fail with a generic error, making it hard to find where the typo is.

Lightning CLI will help you ensure your components are LockerService ready, but also lint your code to highlight potential issues. For instance, the following code has a small typo:

var navEvt = $A.get(“e.force:navigateToSObject”);
    “recordId”: oppId;

This will break Lightning Experience with a error that isn’t really helping you understand the root cause:

If this is part of a big application, it can be hard to find the issue. Running Lightning CLI will just let you know where the typo is, which can save you hours !

Bonus tip: cmp is not defined

One bonus tip: for your firsts Lightning Components, you’ll often end up copy/pasting code until you remember the framework syntax, like for doing a server-side call. When creating a controller, you’ll start with an empty function created for you:

myAction : function(component, event, helper) {


This is great, except that most of the code samples available in the Lightning Component Developer Guide are using a component variable named cmp, and not component. Beware of this even if it’s easy to fix by replacing one by the other. If I had received 1€ every time I made this mistake, I would be rich today !!

Next Steps

So now you’re ready to start you first Lightning Component ! Of course, a great place to begin is the Trailhead website. There are several Lightning modules, but I personally like these ones:

I would also recommend watching Anup ☁ Jadhav’s great talk from London’s Calling about Lightning Apps:

Should you have any question, these are great places to go:

Finally, you can of course reach out to me directly on Twitter.