I have been using Storable Actions to help reduce the amount of identical calls that are going back to the server. Everything is working great but I have a question surrounding how this works across multiple components.

Currently, I have a standard pattern where repeated data uses an individual component to display the repeated data. Think of rows in a table. I have one component representing the table, and another component representing the row. I then repeat the component in an iteration to display all rows.

My question surrounds whether or not I get a cache hit if each row calls the same action, for the same data.

  • This is a question I've pondered a bit - and at the moment, I'm pretty much just supplying the rows with their data because I think even with storable actions, you are going to get a call to the server for each row, depending on how you filter the data. May 18, 2017 at 22:04

1 Answer 1


I'm using a storable action (to get some metadata) that is called from multiple components. I see the behaviour mentioned in the Storable Actions documentation that when multiple requests are made for the same key:

The responses to idempotent actions can be cached and quickly reused for subsequent identical actions. For storable actions, the key for determining an identical action is a combination of:

Apex controller name
Method name
Method parameter values

multiple network requests (as monitored in Chrome's Network tab) are not made. The action callback happens, but the data comes from a client-side cache. So I am seeing "cache hits".

(Incidentally, the Salesforce Lightning Inspector Chrome Extension does report the "Storage Key" being used but always reports a "Storable Cache Hit" of false which is not consistent with Chrome's Network tab.)

For reasons I don't understand, I am seeing a second request launched a few seconds later. This Lifecycle of Storable Actions documentation mentions a refresh process that may be involved.

  • I love this answer, specifically the last part as I had observed the same behavior. Thank you for the quick, in-depth answer! May 18, 2017 at 22:22
  • 1
    @techbusinessman Yeah it took me a while to convince myself that the caching was working.
    – Keith C
    May 18, 2017 at 22:24
  • Just to confirm - this wouldn't work if, for example you had a list of Opportunity rows and queried for each opp separately, correct? (I mean, it couldn't) - what you are talking about is, say user config data, userid, that kind of thing, correct? For the Opportunity example, would you feed the list to the children or get them to query for themselves? May 18, 2017 at 22:26
  • 1
    @CasparHarmer Yeah two separate queries for two different Opportunity Ids will mean two requests, but if other components query for the same Id value the query will be satisfied from the cache. (Seems like for individual records, force:recordData's caching will be the preferred way to go in the future.)
    – Keith C
    May 18, 2017 at 23:02
  • 1
    Yes I'm looking forward to the lightning data service. Should be awesome. May 18, 2017 at 23:03

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .