Over the last 18 months Desynit have worked on a number of projects involving complex custom Lightning Components. The Lightning Component Framework has come a long way in that time, and many of the initial roadblocks we encountered (like missing documentation, and problems with components in changesets) have been fixed in recent releases. However, the persistent caching of components in development has remained a frustration.
To put it kindly, LEX has been known to be a little sluggish. To maximise performance, Salesforce implements an aggressive caching policy to minimise time consuming round-trips to the server. This may be sensible in a Production environment, where components rarely change, but forcing multiple page refreshes (often taking 5 seconds or more) to view changes is a major overhead.
When viewing markup changes we can at least keep hitting F5 until new elements appear. Itโs much more problematic if we are updating the JavaScript code in our controller or helper files, because there may not be a visual clue to let us know if weโre viewing the latest version of our component.
To minimise the hassle this can cause, we got into the habit of inserting a spurious div
or p
element into our markup, incrementing the content each time a change was made anywhere in the component:
<aura:component implements="flexipage:availableForAllPageTypes">
<div>BBB</div> <!-- update me for changes -->
<div style="border: 1px solid black; border-radius: 25px; padding: 20px;">
<p>Thing 1</p>
<a onclick="{!c.first}">Click Me First: </a><br/><br/>
<a onclick="{!c.next}">Click Me Next: </a><br/><br/>
<a onclick="{!c.last}">Click Me Last: </a><br/><br/>
</div>
</aura:component>
Not a very elegant solution, but it gets the job done (as long as you remember to update your content).
I came across the official solution for this problem buried away in the 51st minute of a Salesforce Webinar called โBest Practices for Lightning Component Developmentโ.
And just like magic, my Lightning Component is as fresh as a daisy on every load – result! Naturally, you should only consider turning off browser caching in a Developer Org or Sandbox (because nobody updates Lightning Components in Production, right???)
Further investigation shows that this feature has in fact been available since the Spring โ16 release, but I had not come across it before, and this problem has been mentioned by a lot of developers at meetups, as well as on blogs and podcasts that I follow. Looks like we all need to scrutinise the release notes a little more from now on…
Our independent tech team has been servicing enterprise clients for over 15 years from our HQ in Bristol, UK. Let’s see how we can work together and get the most out of your Salesforce implementation.