Lightning Tip: Always Create Admin Friendly Lightning Components

In case you did not realize, Salesforce Lightning components can be one of two flavors:

  1. Aura components – Launched in 2015 and up until early 2019 were called Lightning components.
  2. Lightning web components (LWC’s) – Launched in 2019 and are considered the future of Salesforce development.

Design for Configurability

Whichever flavor you select, the tip in this post applies to both Aura components and the new Lightning web components.

So what does creating Admin friendly Lightning components mean?

In a nutshell, it means making your component as configureable as possible to anyone using it to assemble Lightning pages using Lightning App Builder. This is done by using a meta configuration file for LWC’s or a design resource file for Aura components.

Whichever flavor you chose, the tip in this post applies to both Aura components and the new Lightning web components.

To give you an example of how that is done for LWC’s, let’s look at the code for the eBikes sample app, which can be found here for the LWC version. This is what the HTML for that component looks like:

    <div class="slds-card slds-p-around_x-small">
        <template if:true={searchBarIsVisible}>
                label="Search Key"
        <template if:true={}>
            <template if:true={}>
                <div class="content">
            <template if:false={}>
                    message="There are no products matching your current selection"
        <template if:true={products.error}>
            <c-error-panel errors={products.error}></c-error-panel>

And here is the JavaScript controller file:

import { LightningElement, api, wire } from 'lwc';

// Ligthning Message Service and message channels
import { publish, subscribe, MessageContext } from 'lightning/messageService';
import PRODUCTS_FILTERED_MESSAGE from '@salesforce/messageChannel/ProductsFiltered__c';
import PRODUCT_SELECTED_MESSAGE from '@salesforce/messageChannel/ProductSelected__c';

// getProducts() method in ProductController Apex class
import getProducts from '@salesforce/apex/ProductController.getProducts';

 * Container component that loads and displays a list of Product__c records.
export default class ProductTileList extends LightningElement {
     * Whether to display the search bar.
     * TODO - normalize value because it may come as a boolean, string or otherwise.
    @api searchBarIsVisible = false;

     * Whether the product tiles are draggable.
     * TODO - normalize value because it may come as a boolean, string or otherwise.
    @api tilesAreDraggable = false;

    /** Current page in the product list. */
    pageNumber = 1;

    /** The number of items on a page. */

    /** The total number of items matching the selection. */
    totalItemCount = 0;

    /** JSON.stringified version of filters to pass to apex */
    filters = {};

    /** Load context for Ligthning Messaging Service */
    @wire(MessageContext) messageContext;

    /** Subscription for ProductsFiltered Ligthning message */

     * Load the list of available products.
    @wire(getProducts, { filters: '$filters', pageNumber: '$pageNumber' })

    connectedCallback() {
        // Subscribe to ProductsFiltered message
        this.productFilterSubscription = subscribe(
            (message) => this.handleFilterChange(message)

    handleProductSelected(event) {
        // Published ProductSelected message
        publish(this.messageContext, PRODUCT_SELECTED_MESSAGE, {
            productId: event.detail

    handleSearchKeyChange(event) {
        this.filters = {
        this.pageNumber = 1;

    handleFilterChange(message) {
        this.filters = { ...message.filters };
        this.pageNumber = 1;

    handlePreviousPage() {
        this.pageNumber = this.pageNumber - 1;

    handleNextPage() {
        this.pageNumber = this.pageNumber + 1;

Notice that the searchBarIsVisible and titlesAreDraggable properties use the @api decorator and that the developer has kindly added a TODO comment here suggesting that the normalized value may come as a boolean, string or otherwise.

The reason the values may some across differently is because these two properties are configureable in the design file, but only for Record Pages and Community default pages. This means that anyone can use Lightning App Builder to change those values (well, at least for Record and Community Default pages).

To see how this is done, let’s take a look at the meta configuration file for this component:

<?xml version="1.0" encoding="UTF-8" ?>
<LightningComponentBundle xmlns="">
    <masterLabel>Product Tile List</masterLabel>
        <targetConfig targets="lightning__RecordPage">
                label="Search bar visible"
                label="Product tiles are draggable"
        <targetConfig targets="lightningCommunity__Default">
                label="Search bar visible"
                label="Product tiles are draggable"

Notice there are two targetConfig entries. One is for lightning__RecordPage and the other is for lightningCommunity__Default, but they both define the same properties. Even though these properties have default values of false, anyone assembling the pages for the two targeted page types can change these values in Lightning App Builder.

Consider this Change to the Configuration

Not to be too critical, but I can see room for improvement in the way the productTileList component was configured. After all, there is always room for improvement in anything we do, right?

The first change I would make is to add a description for all the targetConfig properties. The description is typically a short sentence, but it appears as a tooltip in Lightning App Builder. This sentence could be used to indicate to the app assembler that the property value should be either true or false and not any other value perhaps?

The end result would look something like the following (notice the tooltip on the right):

Lightning App Builder used to configure the productTileList component.
Lightning App Builder used to configure the productTileList component.

For more tips about what you can do to make your components configureable, check out this great developer doc page.

Top 5 Lightning Debugging Tips

top5 This month I had the honor of speaking at Texas Dreamin’ 2018 . My topic was Lightning Performance and Debugging Tips for Developers. The talk was a combination of things I went over at last year’s Dreamforce talk about 5 ways to Build Lightning Fast Components and some new stuff I have learned recently about debugging. You can check out the slides here at Lightning Performance and Debugging Tips for Developers.pptx.

The new debugging tips include the following:

# 1 – Check Debug Mode Setting

Debug mode is what you can toggle to allow detailed debug messages to appear in your browsers console log and these messages can really help you not only to debug your components, but they sometimes feature important messages about performance.

For the debug mode, you want that to be enabled in development, so you can get those messages you need as you are developing. Just remember that in production, you want to make sure this is turned off b/c when it is enabled, it means that all the css and javascript that is downloaded to the client is not minified. This means it will take longer to download and longer for your components to render. That is why you do not want it enabled in production.


# 2 – Use the Salesforce CLI Linting Tool

This tip involves using a feature that is available with the Salesforce DX CLI. And in case you are not familiar with Salesforce DX, it is essentially just a set of tools that allow developers to really streamline the whole Salesforce development process through source driven development. But, the particular tool that I want to focus on now is the CLI or Command Line Interface because it includes a linting tool that lets you scan your lightning code and determine whether it is violating any anti-patterns that could be impacting performance or even just causing problems in your code. It will give you messages that explain what is wrong with the code and so you have a chance to address them.

In case you are not familiar with linting, this is just a process of scanning and analyzing code before it is executed to look for known problems. This is a very good proactive development practice to get into. You can get more info about this tool from this link here.

# 3 Use debugger and Dev Tools

If you want to trouble shoot problems as they are occurring in real time you are going to need to work with the browser developer tools, like what you find in Chrome. This next tip has to do with adding a line of code to your Lightning JavaScript code that will call the debugger statement. Doing this will actually pause the execution of your JavaScript and allow you to step through the code and look at the value of any variables you have. It is like setting a breakpoint in your code and you can see an example of it below where I have added it to the code for the createNewRace function.


To see this work, you will need to use your browser developer tools. Once you do, and you get to the place in your code where the debugger line is executed, you will see something like the following when it is paused in the debugger.


To get more info about using the debugger statement, you can check out this URL which sends you to a video that was done by one of the Chrome tools technical writers where he walks you through using it.

# 4 – Use Lightning Testing Service

The next tip has to do with the tool that you may not have heard of since it is only in Pilot and that is the Lightning Testing Service. This is a set of tools, that is actually available as open source on GitHub and it allows you to create test suites that are used specifically to unit test your JavaScript code, such as what you see here.


You know how you have to write unit tests for your Apex server-side code, but there is not really anything for testing the client-side? Well, this is it. Test suites can be written in Jasmine or Mocha or you can create your own wrapper if you are using some other test framework. 

You can go to the URL you see here to see a great article that was written on the Salesforce Developers Blog about how to get started with it. And what you see here is just a listing of all the tests that are provided out of the box when you install the testing service.


It comes with 18 tests which get you started writing your own test suites. It is pretty easy to use and if you are serious about lightning development and want to create very stable apps, then this a must have tool for you.

# 5 – Use the Lightning Inspector Plugin

The last tip is to use the Lightning Inspector Plugin, which is a Google Chrome plug-in that you can install to tell you about what is going on under the covers for your Lightning components. Once you do you will have access to a new Lightning tab in the Chrome Dev Tools, which you may be able to see below. Notice the tab that is surrounded by a red rectangle.


I plan on doing another post soon where I go over in detail some of the great info you can get from this tool, But for now, I strongly encourage you to go ahead and install it. You can simply bring up the Lightning Experience in Salesforce and access your Developer Tools to check it out.








Top 6 Tips for Working with Lightning Testing Service

Lightning Testing Service (LTS) is a set of tools designed to help you test the JavaScript in abtyour Lightning Components. Even though it is still in pilot, if you are developing Lightning Components, I highly suggest you take the time to check it out. Using this tool will be very important in ensuring that your components behave as expected.

As far as what LTS contains and how you use it, I suggest you refer to this Getting Started With Lightning Testing Service post by Christophe Coenraets from the Developer Relations Group. He does a great job of getting you started building your first test suite.

In this post, I will just highlight the super important things you need to know about working with LTS:

  1. You do not have to install SalesforceDX to work with LTS, but I really think you are missing the point if you try to. SalesforceDX not only makes it much easier for you to work with LTS, but the thinking behind using SalesforceDX is very similar to why you need JavaScript testing. Testing your Aura methods with unit tests and manually testing your components is not enough to ensure that your lightning components are behaving correctly. It also does nothing to ensure that they will continue to behave correctly as you introduce more code.
  2. Wrappers are ONLY provided for Jasmine and Mocha. If you want to use another testing framework, you will have to build your own wrapper, which will probably take you about a day to do. But, Jasmine is very easy to use and unless you are already using another JavaScript testing framework, I suggest you stick to Jasmine.
  3. You do not install or use LTS in production. Seriously! This is just for development environments and even better it is for scratch orgs that you create using SalesforceDX.
  4. LTS includes sample code to get you started. This includes not only the Jasmine and Mocha wrappers, but a Lightning App called that you can use to jump start your testing. Just follow the instructions in Christophe’s blog post and you should be up an running in no time.
  5. You do have to create and upload Static Resources that contain the JavaScript code for your Jasmine test suites. But, SalesforceDX provides commands for doing this easily so it is not quite such a cumbersome process to replace code as you are doing your development.
  6. This is the most important tip: Do not use LTS to test your server code. Keep your client and server-side testing separate. When calling Apex server methods that insert records with LTS, the data that is created is NOT rolled back. You have to be responsible for rolling back the data yourself. You can still mock the server call and an example of this is provided in Christophe’s blog post as Scenario #6. This is the recommended and best way for you to test the server code in your lightning Components. You can still create (and you actually still need to) regular unit tests to test that your Aura methods work as expected.

Ok, that’s it.

Hope it helps and good luck in your journey towards becoming an AWESOME Lightning Developer using Lightning Testing Service.



5 Ways to Build Lightning Fast Components

This post is based on a talk I gave twice at this years Dreamforce.

The five tips I cover here were hand picked by me out of a whole bunch of stuff I discovered while creating my latest Pluralsight course about Lightning Best Practices. The course will be released soon, so stay tuned and I will let you know. All of these tips are pretty simple to implement and I think they represent the quickest and easiest things you can do to get better performance.

So, in David Letterman style. here they are from last to first:

# 5 – Check your Settings

Specifically, you want to check the values for debug mode and component caching, which should have different values depending on whether you are in production versus development.

Debug Mode

Debug mode is what you can toggle to allow detailed debug messages to appear in your browsers console log and these messages can really help you not only to debug your components, but as you will learn about soon, they feature important messages about performance.

For the debug mode, you want that to be enabled in development, so you can get those messages you need as you are developing, but in production, you want to make sure this is turned off b/c when it is enabled, it means that all the css and javascript that is downloaded to the client is not minified, which means it will take longer to download and longer for your components to render and that is why you do not want it enabled in production.


Component Caching

Component caching has to do with whether pages will be cached to specifically improve performance, which is why that one is so important.

For the component caching, the settings should be the opposite and you want caching disabled in development, because while you are making changes to components and testing how they render, you do not want to have to hit your browser refresh several times before you see your changes which is what will happen if it is enabled. But, in production, where changes to the code are not happening, you want to make sure caching is enabled, since this will result in faster component rendering.


# 4 – Use <aura:if> for Conditional Rendering

To do conditional rendering in Lightning, you could use a technique known as css toggling and for a long time this was actually the way even Salesforce recommended you do toggling in the official docs. But in fact, what we now know is that you do not want to do this and the reason why is that when you use this method, any components inside the css toggled code (and most importantly any event handlers associated with those components) are rendered right away.

The alternative is to use the aura:if tag. Using this means that anything inside the aura:if will not actually be rendered until the condition is true. So in the example below, the event handlers associated with the lightning button will not be active until the aura:if condition is true.

<aura:if isTrue="{!v.isVisible}">
             <lightning:button label="Submit"
            onclick="{!c.newRecord}" />

# 3 – Check your Console Log

The number 3 tip is a reminder to always check your browsers console log because not only can you use this for debugging your components, but the lightning development team now will push performance warning messages to the console log and so even if your component is rendering fine and doing everything you want it to, you could have a performance issue and not even be aware of it.


You can access the Console log for the Google Chrome browser by right-clicking inside the browser and selecting Inspect. But know that these messages will only appear when debug mode has been enabled, so this is something you want to only check for in your development org.

# 2 – Use the Lightning Data Service whenever possible

The Lightning Data Service is just way cool and offers a whole bunch of great features. If you do not know about it, check out this great Trailhead that tells you all about how to use it.

The best thing about the Lightning Data Service (or <force:recordData> tag) is that it provides a single cached response and this can have a big impact on performance.

Let’s say you have three components that are all using the force:recordData tag. Each one will make a request for data through the Lightning Data Service Controller, and those requests will be funneled into one single request which is sent to the Salesforce server.

But what is returned is a response that will be stored in a shared data cache and also returned back to the two components that started all this. And this means that not only will those two components be able to retrieve the data faster than two components that were using their own apex controllers.

And if a third component that needed that same data were to come along, it would be able to get a cached response almost immediately without even having to make a call to the server. Boom!


# 1 – Use Storable Actions whenever possible

So here we are at the number one tip and it is to use storable actions whenever possible, which essentially allows you to take advantage of caching and get all the benefits that you just saw demonstrated, even when you are not using the Lightning Data Service.

And a good example of this can be seen with a component that needs to access a list of data (which is something that the Lightning Data Service currently cannot handle, since it only works with a single record).

When paging through a list of records that use storable actions, after the pages are rendered once, the next time they are returned to, the rendering will happen in a fraction of the original rendering time. This can results in significant performance savings when a user needs to page through a long list of records.

And to take advantage of caching, all you have to do is add a single line of code right after you define the action, such as in the following example:

​var action = component.get('c.getRacesDB');
​action.setCallback(this, function(response) {
​            // Code here to handle the response

If you found this article useful, you might want to checkout my latest course on Pluralsight titled, Lightning Component Development Best Practices, where I talk about base lightning components and a lot more.

Lightning Best Practice: Handling FLS Exceptions Gracefully

If you found this article useful, you might want to checkout my latest course on Pluralsight titled, Lightning Component Development Best Practices, where I talk about base lightning components and a lot more.

If you are a Visualforce developer, then you may be surprised to learn that FLS (Field Level Security) and CRUD (Create Access Delete and Update) permissions are NOT handled automatically in your Aura-enabled code.

And in case you do not know, Aura-enabled code is the code used for Lightning components and most of this code is used to access the data in your Salesforce org. The gotcha here is that unless you are specifically checking permissions in this code, then it is possible your Lightning components could be unintentionally exposing sensitive data from your Salesforce org. 


The Problem

While there are code examples out there (such as this one on in the Lightning Developer Guide), I think there is a fundamental flaw in most of these examples. And that flaw is that they do not handle exceptions gracefully.

To demonstrate, let’s see take a look at some code that is very similar to the code used in the official Lightning docs. This code is used in the Controller of a Lightning component which lists data from a custom object called Race.

String [] raceFields = new String [] {'Id','Name','DateTime__c',
'Location__c','Attended__c','Type__c','Results__c' };

Map raceMap =

for (String field : raceFields) {
   if (!raceMap.get(field).getDescribe().isAccessible()) {
      throw new System.NoAccessException();
         return null;

res.races = [SELECT Id, Name, DateTime__c, Location__c,
               Attended__c, Type__c, Results__c FROM Race__c
            ORDER BY DateTime__c desc
            LIMIT :pSize OFFSET :offset]; 
return res;

This code will first check to see if all the fields that need to be queried are accessible and if any one of the fields is not accessible, it will throw a NoAccessException.

Seems ok, right?

Well to begin, let’s take a look at what you would see in the browser if this code is run and the user does NOT have access to one of the fields:



Not only is this message ugly, it is extremely unhelpful.  Surely, there must be something better?

Option 1 – a Better Error Message

Well, the first option you have is to simply replace the code that throws a System.NoAccessException, with code that throws an AuraHandledException, such as this:

 for (String field : raceFields) {
    if (!raceMap.get(field).getDescribe().isAccessible()) {
        throw new AuraHandledException(
            'Were sorry, but you do not have access to this field: ' 
            + raceMap.get(field).getDescribe().getName());
        return null;

The message you will see now when one of the fields is not accessible is this:


Much better, don’t you think?

Option 2 – Handling the Exception Gracefully

But wait, it can get EVEN better…

Instead of returning null when a field is not accessible, we can instead make a few more changes to the code, such as this:

String [] raceFields = new String [] {'Id','Name','DateTime__c',
            'Location__c','Attended__c','Type__c','Results__c' };
Map raceMap = 

List fields = new List();
String query = '';
for (String field : raceFields) {
    if (raceMap.get(field).getDescribe().isAccessible()) {
if(fields.Size() > 0) {
    query = 'SELECT ' + String.join(fields, ',') + ' FROM Race__c';
    query+= ' ORDER BY DateTime__c desc LIMIT ' + pSize;
    query+= ' OFFSET ' + offset;
res.races = Database.query(query);
return res;

In this version, I am still looping through all the fields to see if they are accessible, but rather than throwing an exception when even one field is not accessible, I am instead adding the accessible field to a list I created called fields. I am then building a dynamic query string using only the fields that are accessible and finally just executing the query using the database.query method instead.

The result is that when the component renders, rather than seeing any error message at all, the user sees the list of races. But, any fields that are not accessible are just left blank.

Now, I happen to think this is the best solution. What do you think?

If you found this article useful, you might want to checkout my latest course on Pluralsight titled, Lightning Component Development Best Practices, where I talk about handling FLS exceptions and a lot more.

Lightning Best Practice: Adding Pagination to Lists


What happens to a Lightning Component that displays a list of data without pagination?

It is probably doomed to suffer from performance problems and who wants to build a component that is doomed? Certainly not you, right?

It’s possible that Salesforce might release a pagination component at some point in the future, but until they do, you will need to roll out your own. Fortunately, it is not too terribly complicated and in this post I will walk you through how to do it.

To begin, I must give credit where credit is due and acknowledge that the paginator component I am using in this post is almost identical to the one used in the Dreamhouse application (which if you have not checked out, you really need to do so).

The markup code for the Paginator component is as follows:


And the Controller code looks like this:

	previousPage : function(component) {
        var pageChangeEvent = component.getEvent("pagePrevious");;
	nextPage : function(component) {
        var pageChangeEvent = component.getEvent("pageNext");;

Additionally, I use a component event called PageChange which looks like this:

Ok, so I have a component that currently renders a list of race data. To make it work with the paginator component through, I will have to make a few changes to both the markup,  controller and helper, along with the Apex Controller it references.

The new version of the markup looks like this:


The Modified controller (seen below) now includes two new actions named onPagePrevious and onPageNext and these are referenced in the Paginator component.

    doInit : function(component, event, helper) {
    handleAddToRaces : function(component, event, helper) {
        helper.addToRaces(component, event);
    onPagePrevious: function(component, event, helper) {
	var page = component.get("") || 1;
        page = page - 1;
        helper.getRaces(component, page);
    onPageNext: function(component, event, helper) {
	var page = component.get("") || 1;
        page = page + 1;
        helper.getRaces(component, page);

And the getRaces function in the Helper file has been modified to look like this:

// Added new parameter called page to pass in the page number
// If no page parameter is passed in, it will just default to 
// a value of 1 and this is the case on the initial call for 
// the doInit action
getRaces : function(component, page) {
    var action = component.get('c.getRacesDB');
    // Added the pageSize variable which is passed in as an attribute
    var pageSize = component.get("v.pageSize");
    // Added code to set the new parameters that are now passed on 
    // to the Apex Controller Code
    action.setParams({"pageSize": pageSize,
          	      "pageNumber": page || 1
    action.setCallback(this, function(response) {
        var state = response.getState();
        if (component.isValid() && state === "SUCCESS") {
            // Instead of just returning all the data
            // as a list, I will get back a result
            // object which is defined in the Apex Controller
            var result = response.getReturnValue();
            component.set("v.races", result.races);
            // Added code to set the values for the page, 
            // total and pages attributes
            component.set("v.pages", Math.ceil(;
         } else {
            //Handle errors
            var errors = response.getError();
            if (errors) {
               if (errors[0] && errors[0].message) {
                   component.set("v.errorMsg", errors[0].message);
                   component.set("v.isError", true);
            } else {
                component.set("v.errorMsg", "unknown error, response state: " + 
                component.set("v.isError", true);


The last thing to do is to modify the code in the Apex Server Controller, which will now look like this:

public with sharing class ListRacesController {

    // Changed the return value from List to PageResult
    // which is defined in the inner class below Also added two
    // new parameters for the pageSize and pageNumber
    public static PageResult getRacesDB(Decimal pageSize, Decimal pageNumber) {
    	// Added new variables
        Integer pSize = (Integer)pageSize;
        Integer offset = ((Integer)pageNumber - 1) * pSize;
        Integer totalRows = 0;
        // Instead of just returning a List of races from a single
        // query, we are now returning a PageResult
        PageResult res = new PageResult();
        res.pageSize = pSize; = (Integer) pageNumber;
        // The first query is used to fetch the data that will
        // be displayed and it will be limited to return just 
        // the data for the particular page it needs to render
        res.races = [SELECT Id, Name, DateTime__c, Location__c,
		     Attended__c, Type__c, Results__c FROM Race__c
		     ORDER BY DateTime__c desc
		    LIMIT :pSize OFFSET :offset]; 
	// We have to do a separate aggregate query to get 
        // the total number of records since this will be
        // used to compute the offset = [SELECT Count() FROM Race__c];
        return res;
   // Added PageResult class which defines the 
   // results returned from the getRaces method
   public class PageResult {
        public Integer pageSize { get;set; }
        public Integer page { get;set; }
        public Integer total { get;set; }
        public List races { get;set; }

And that’s it. I now have a component that will by default only display 5 races at a time and allow the user to move between the pages using the arrow buttons.

And now I can rest – assured that my component (which honestly could use some other improvements), will not perform miserably when the number of races eventually climbs to a very high number.

Pretty neat, right?

Want to learn about other improvements? Well, the next one is to add caching to this same component and believe it or not, I can do it with a single line of code. Check out this post for more info. And stay tuned because this blog will continue to feature lightning best practices such as these.

EDIT: Below is the requested markup and code for the inner RaceV2 component, which actually includes the individual race data.

First, the Markup:


And now the Helper Resource:

	updateRace :function(component) {
        var race = component.get("v.race");
        console.log("Calling updateRace");
        var action = component.get("c.updateRaceDB");
        action.setParams({ "race" : race });
        action.setCallback(this, function(response) {
            var state = response.getState();
            if (component.isValid() && state === "SUCCESS") {
                console.log("Race successfully updated");
            } else if (state === "ERROR") {
                var errors = response.getError();
                if (errors) {
                    if (errors[0] && errors[0].message) {
                        console.log("Error message: " + errors[0].message);
                } else {
                    console.log("Unknown error");
            } else {
                console.log("Action State returned was: " + state);



If you found this article useful, you might want to checkout my latest course on Pluralsight titled, Lightning Component Development Best Practices, where I talk about pagination and a lot more.

Lightning Best Practice: Conditional Rendering

For WhichMethoda long time I thought the best way to conditionally render elements in a Lightning component was to use CSS toggling. I thought this because if you look at the official Lightning Developers Guide where it talks about Dynamically Showing or Hiding Markup, the guide actually writes,

“Use CSS to toggle markup visibility. You could use the tag to do the same thing but we recommend using CSS as it’s the more standard approach.”

I have since learned that this is not really a best practice and the best method might be to use the built-in aura:if component. I discovered this by reading through a recently published article about Lightning Best Practices by Salesforce technical Evangelist, Christophe Coenraets in which he writes,

“The general guideline is to use the aura:if approach because it helps your components load faster initially by deferring the creation and rendering of the enclosed element tree until the condition is fulfilled. Components inside an aura:if with the value of its isTrue expression evaluating to false aren’t created and aren’t part of the DOM. Event listeners aren’t created either.”

So, which method is better for conditional rendering?

I do believe that Christophe is correct in stating the aura:if approach should be used generally. But there is a gotcha you really should be aware of when going down that path.

Ok, so let me explain this better with an example. Let’s assume you wanted to either render an error message if one was encountered while accessing data, or a table listing the data that was retrieved. You might use some markup code such as this:


The errorMsg attribute would be initially set with a value of blank in the doInit action. It would only have a value other than blank when an error was encountered.  And this would cause the message to be displayed. Makes sense, right?

The solution above will certainly work, but if you examine your console output, you will see a message such as the following:

Screen Shot 2017-05-30 at 5.37.15 PM

So, what is this message about?

Well, it is a performance warning message telling you that you have an aura:if tag that was switched from true to false in the same rendering cycle and this can cause avoidable work for the framework that slows down rendering time.

But, didn’t I start all this by suggesting that using the aura:if for conditional rendering was a better alternative?

It’s ok, there is a simple fix for this.  Instead of checking to see if the errorMsg attribute has a blank value, what you need to do is to add a second attribute called isError and make sure it uses a default of false, like this:

<aura:attribute name=”isError” type=”boolean” default=”false” />

You can then change the markup code to look like the following and you will no longer receive the warning message in the console.

Screen Shot 2017-05-30 at 6.23.41 PM

The message I am hoping to get across here is that, you really need to be aware of what is happening in terms of the Lightning Rendering Lifecycle, as that can have a big impact on performance.  AND most importantly, you need to always check your console log to look for performance warnings.

Good tip: Always check your console log for performance warnings.

I have no doubts that Lightning development is the future of all Salesforce development and that the future does look bright. And amazingly fast. It is just going to take a little time to work out all the kinks. And time for us developers to learn about what best practices are needed to make it really run that fast.

If you liked this post, then you might want to checkout my new course about Lightning development on Pluralsight titled, “Customizing Salesforce with Lightning Components: Getting Started