For a 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:

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.

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”