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
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:
- 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
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.
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.
Brightgen Careers | Brightgen
For 10 years organisations have relied on BrightGen to show them what Salesforce — and their business — is capable of…
You can find my (usually) more technical thoughts at the Bob Buzzard Blog