<< 30 April 2017 | Home | 02 May 2017 >>

! vs # in Salesforce Lightning Components

Often when you read tutorials on developing Salesforce Lightning components they all contains expressions when passing data and variables into other components. Like say you have an attribute as an array and would like to iterate over the elements:

<aura:attribute name="arr" type="string[]" default="['foo', 'bar', 'baz']" />

<ul class="slds-list--dotted">
<aura:iteration items="{!v.arr}" var="item">
    <li>{!item}</li>
</aura:iteration>
</ul>
Now this is a very simple example but it shows the point. This component shows a simple bullet list with items - when the array attribute ("arr") changes the list will recalculate and update. Often this is what you want but sometimes the array will never change. A better way to do this - especially with arrays as Javascript has not easy / performant way to see if an array actually changed - is to use # instead of ! in your expressions. # means that the expression will not automatically update when the attribute is changed which may speed things up considerably when there are many attributes and many components on the page. Fewer attributes to monitor for changes by the framework leads to better perfornance.
<aura:attribute name="arr" type="string[]" default="['foo', 'bar', 'baz']" />

<ul class="slds-list--dotted">
<aura:iteration items="{#v.arr}" var="item">
    <li>{#item}</li>
</aura:iteration>
</ul>
Another reason for using # instead of ! could be to control the data binding between parent and child components.

There is a nice article on the matter in the Salesforce documentation - Data Binding Between Components.

Salesforce week 24

Last week was all about getting the next component for my customer into production. For one of their business lines they had some very specific requirements for a search so we built a search from scratch. Now Salesforce comes with a built in fulltext search functionality but the customer only wanted results from a specific object type and a specific record type at that. So that's what we built. The solution was deployed on Thursday and have been running since. Main hickup in the deployment was some weird "cannot access childNodes of null" errors that kept surfacing from the Lightning component I built to display what search filters were in place. The component was basically just a wrapper around a number of arrays showing the filters as pills and showing a filter count. The markup was basically like this (c:Pill is simply a wrapper component for the pill):

<div class="filters">
    <div>{!v.filtersCount} filters added</div>
    <div aura:id="filters_expand" class="">
        <aura:iteration var="filter" items="{!v.accountDisplayObjects}">
            <c:Pill displayText="{#filter.displayText}" object="{#filter}" colorClass="orange" />
        </aura:iteration>
        ...
        ...
        <aura:iteration var="filter" items="{!v.geoDisplayObjects}">
            <c:Pill displayText="{#filter.displayText}" object="{#filter}" colorClass="lightorange" />
        </aura:iteration>
    </div>
</div>
We kept however getting the errors and I narrowed down the issue to being with the aura:iteration components and if multiple subsequence display object arrays were being changed after one another. The fix turned out - as always - to be very simple. I simply wrapped each aura:iteration component in its own span-tag.
<div class="filters">
    <div>{!v.filtersCount} filters added</div>
    <div aura:id="filters_expand" class="">
        <span><aura:iteration var="filter" items="{!v.accountDisplayObjects}">
            <c:Pill displayText="{#filter.displayText}" object="{#filter}" colorClass="orange" />
        </aura:iteration></span>
        ...
        ...
        <span><aura:iteration var="filter" items="{!v.geoDisplayObjects}">
            <c:Pill displayText="{#filter.displayText}" object="{#filter}" colorClass="lightorange" />
        </aura:iteration></span>
    </div>
</div>
Oh well another bug bites the dust and another lesson learned...

Besides this we got a new team member as another one of the existing team members is graduating into management. So now we also have a Salesforce Business Architect from the UK office. Nice.

What did I learn

  • Span your aura:iteration components
  • Troubleshooting Lightning Style
  • There is a reason for having a staging environment but make sure it contains representative data...

Status after this week

Trailhead points: 85325
Trailhead badges: 100
Certifications: 5 (Salesforce Certified Administrator, Salesforce Certified Platform App Builder, Salesforce Certified Advanced Administrator, Salesforce Certified Sales Cloud Consultant, Salesforce Certified Service Cloud Consultant)

Tags :