Visualforce to Lightning Components in 5 Easy Tips

Introduction

When the Lightning Components framework first became available to developers after Dreamforce 14, I was all over it like a rash. Up until that point I’d used JavaScript frameworks for specific purposes, like jQuery Mobile for HTML5 mobile applications, and while I’d certainly learned a few lessons about how to structure my code for maintainability, re-use wasn’t something I’d really worried that much about. If I needed something similar for another project, I’d just copy the original as a base and change it as necessary, much like how I built most of my Visualforce pages. Moving to Lightning Components I had to rethink how I built my front end applications so that I could get the most out of it.

I have no doubt there are a huge amount of people in the Salesforce ecosystem who are able to produce an application with a Visualforce front end, so here I’m going to share my top tips for starting the journey with Lightning.

1. Start with Baby Steps

The biggest issue I see with Visualforce developers starting out with Lightning is a lack of familiarity with JavaScript. If you are in this position, start small! Rather than going for a complex UI with lots of bells and whistles, made up of masses of components that don’t yet exist, approach it like a Visualforce page, but with as much of the business logic as possible in the JavaScript controller/helper. Have a single Lightning Application (think of this as an URL addressable component) that contains all of your markup and logic. Treat the Apex controller as the database access layer, purely for querying or writing data, and manage everything else on the front end. This keeps you in the paradigm familiar from Visualforce of one large form containing all the data the user can influence and a “controller” that applies logic based on the user’s action. Using this approach you can gain familiarity with writing business logic in JavaScript and key Lightning concepts such as attributes and event handlers. If you aren’t that familiar with JavaScript, this is an excellent time to learn more about it.

Once you get a handle on things at this level, you can then take advantage of the rest of these tips.

2. Use Inheritance

One thing that Visualforce didn’t support was component inheritance. If you want to extend an existing component you’d either clone and enhance or wrap it. Lightning Components are different, in that components can directly inherit from each other. This means, for example, you can have a lookup super component that allows a user to search for records and select from the matches, and subcomponents that provide specific searching capabilities such as a simple match against the record name or a subset of records that share the same master-detail relationship. Then when you need a slightly different variant of this, you just create a new subcomponent rather than creating a slightly different copy.

3. One Super Component to Rule them All

Following on from inheritance, the best decision I ever made with respect to Lightning was a single super component that all other components inherit from. This single super component provides common functionality that every other component leverages, such as:

  • Logging
  • Action response handling
  • Surfacing and clearing down error messages
  • Showing and hiding working spinners

and much more.

Having this functionality centralised has a huge advantage over striping it across each component — it’s easy to change. An example of this is error messages : originally I built a component that use the Lightning Design System toast styling and managed lists of messages that were displayed then cleared down after a period of time, as the standard force:showToast component didn’t have that styling. Now that the standard component does have the styling, I have to change one method in my super component and all of my other components now use that. If I’d managed this directly from each subcomponent, it’s highly likely I’d never find time to change all of them, so I’d end up with a strange hybrid where half of the components used my custom solution and half used the standard. Another great example is logging — my super component delegates to console.log unless it detects it is inside Salesforce1, in which case it uses a different mechanism to make the debug information available.

4. Name your Components

Debugging Lightning components can be difficult, especially when you have a large number of the same page and they are interacting with each other as the user changes values, so knowing which component generated which log message is vital. If you have taken my advice from tip 3, you simply add a name attribute to the one true super component and include this in all log messages generated by that component. A great example of a virtuous circle if there ever was one.

5. Use Exceptions

JavaScript supports exception handling just as well as Apex, but I rarely see it used. I find it really helpful as, depending on where an error occurs, the Lightning Component framework may not surface it to you, and if it does the underlying error message may not be that helpful (‘k is not defined’ always needs a little more digging to find out what the underlying error message is!). The syntax for JavaScript exception handling is slightly different, but not so much that it should be a struggle to adopt it. The snippet of code below attempts to push a value onto a variable that is null:

Executing this throws the expected exception:

Exception occurred TypeError: Cannot read property ‘push’ of null, 
stack = TypeError: Cannot read property ‘push’ of null
at Object.<anonymous> (/Users/kbowden/…)
at Module._compile (module.js:541:32)

6. Bonus Tip

Yes, I know I said there would be 5 tips, but this is an important one and only takes up a few words.

JavaScript is case sensitive

I’ve lost count of the amount of issues that I’ve seen where case sensitivity is an issue. From attributes named ‘obj’ but referred to in code as ‘v.Obj’, through to trying to access the id of a Salesforce record via the ‘id’ field (it needs to be ‘Id’), it’s the gift that keeps giving, so it’s good to get into the habit of looking for the simple fix first.

I’m better known in the Salesforce community as Bob Buzzard — Umpteen Certifications, including Technical Architect, 5 x MVP and CTO of BrightGen, a Platinum Cloud Alliance Partner in the United Kingdom who are hiring.

You can find my (usually) more technical thoughts at the Bob Buzzard Blog