Aura:If (a saviour OR a destructor) – Best Practices

Aura:If (a saviour OR a destructor) – Best Practices

Aura:If – A recommended solution to improve Lightning Component Performance.

With this post let’s check how far is this true and what are the boundaries of using aura:if in a component.

Also Read : Designing And Developing Lightning Component – Best Practices

Advantages Of Aura:If
  • It takes care of the data filtration process in the markup itself and no javascript is needed to check the condition.
  • It only loads the markup if the condition is true else the markup is not loaded or destroyed from the DOM.
  • Along with unnecessary markup, it also destroys unnecessary listeners associated with the markup.

Above advantages of aura:if can definitely boost your component’s performance with a great margin, especially on lower configuration devices where the browser does not have enough bandwidth to handle a lot of DOM and listeners.

Where can this fail?

Aura:If is a good solution to get better component performance on the browser side, however, this will fail if you will use too many aura:ifs in your component. That means if you use aura:if within an aura:iteration or any loop, your component may start behaving badly and you may start noticing poor performance. The reasons are unknown to me, however, I think it is due to more calculation happening on the browser level and the time taken to destroy or generate the markup by aura:if.

Can we think of CSS as an alternative in this situation?

No, CSS cannot be an alternative in this situation as CSS will always hold the unnecessary markup and listeners which is enough to eat up your browser’s memory.

What is the alternative?

Javascript, yes, Javascript is an alternative to aura:if in these situations. You need to handle your data filtration part in Javascript and pass the filtered data to aura:iteration. Also, handle the dynamic condition in javascript.

Use Case and Performance Comparison

The use case I have is to generate an HTML table with ~2000 rows.

  • Each row is having a condition “Show_Me” which will help in deciding if the row should be visible or not.
  • Each row is having 4 different columns to be shown.
  • Rendering of the column depends on the data it has within it. For example, Number column should only be rendered if the value is greater than 5.

The above use case requires data filtration on row level and then in column level. There are two ways to handle it, 1. Using Aura:If Or 2. Javascript

Let’s see the performance metrics that I have observed while implementing using both approaches.

Approach 1- Using Aura:If

  • Time taken to render the page: ~8 sec
  • More than 38% of the time is being consumed by aura:if
aura:if consumed 38% of the time
Total time consumed is ~8sec

Approach 2- Using Javascript

  • Time taken to render the page is ~2.4sec
None of the components took more time in this case
Total time taken to render is ~2.4sec
Coding Time

Approach 1 Code – Using aura:if

Component – AuraIfTesterY.cmp

Controller – AuraIfTesterYController.js

Helper – AuraIfTesterYHelper.js

Approach 2 Code – Using Javascript

Component – AuraIfTesterF.cmp

Controller – AuraIfTesterFController.js

Helper – AuraIfTesterFHelper.js

Server Controller (Same for both approach) – AuraIfTester.apxc

Thanks to “Manish Kumar – Managing Director of MTX Technologies” for introducing me to this scenario and explaining it very well. 

So from now on, avoid using aura:if inside iterations as this can result in bad performance. Please do share your queries and feedback in comments.

Manish Choudhari

I am a certified Salesforce Application & System Architect and Developer working on Salesforce Technology since 2014. Currently, I have 14 Salesforce certifications along with OCPJP (Oracle Certified Profession JavaSE6 Programmer) working in Hyderabad as a Technical Engineer. Writing technical blogs, learning new technologies and frameworks and sharing knowledge is my hobby.

This Post Has 4 Comments

  1. Avatar

    We explained with an example. Thanks Manish for your valuable post and time.

  2. Avatar

    Great write up! I think it should be mentioned that is simply a component, like all other components with the only difference being the v.body attribute does not get rendered if the initial server-side evaluation of the expression is evaluated false for v.isTrue and v.body is destroyed if v.isTrue becomes false. If the evaluation is indeterminate on the server side then it will be evaluated at run-time (likely resulting in a round-trip for components inside the v.body–but I cannot confirm this).

    We must remember component creation invokes a new, full component lifecycle phase which is a very expensive operation. Additionally, component destruction invokes the creation of another if the v.else attribute is defined. The specifics aren’t detailed in the documentation, but the aura framework creates “branches” of components rendered by aura:if, which I can speculate that the components rendered are disjoint from the application component tree in memory but remain a part of the component hierarchy via reference. This would likely cause repetitive creation/destruction not only costly for processing time from a new component lifecycle but also costly in terms of memory resources as each v.body rendered by an aura:if has its own component tree in memory in addition to being a component itself.

    Best practices should be followed to limit as much as possible conditional markup rendering. Your analysis is the perfect example reinforcing conditional rendering should never be used in iterated markup. Data returned from the server should also be well-structured, idempotent, and concise. This is not only true for performance but also security reasons. Imagine if your application has an elevated user that uses the same controller to fetch data and a developer used aura:if to conditionally display markup based on the user type to conditionally display data in the markup. I have actually witnessed this before. All a savvy user has to do is simply inspect the data returned from the request in the response body to access the data that is supposed to be confidential and secure from users without elevated permissions. For this reason, I do not think filtering the data in javascript is not a good approach. If you find yourself doing this, you should always look to the server side code to return _only_ the relevant data to the browser.

    1. Avatar

      Thanks a lot, Cheddar for the advice, and I am really glad that you found this post useful.

Leave a Reply

Close Menu