Shared cache

Two sibling components execute the same key. One fetch serves both; a refetch from either updates both; the inspector shows the single entry they subscribe to.

Two components, one key, one fetch

Component A renders: 4

State IsLoading IsReFetching IsError IsCachedData IsStale ReFetchCount: 1UpdatedAt: 20:32:22
  • delectus aut autem
  • quis ut nam facilis et officia qui
  • fugiat veniam minus
  • et porro tempora
  • laboriosam mollitia et enim quasi adipisci quia provident illum

Component B renders: 4

State IsLoading IsReFetching IsError IsCachedData IsStale ReFetchCount: 1UpdatedAt: 20:32:22
  • delectus aut autem
  • quis ut nam facilis et officia qui
  • fugiat veniam minus
  • et porro tempora
  • laboriosam mollitia et enim quasi adipisci quia provident illum
Key Data Fetching Invalidated Subscribers Updated
["todos","list",5]✓ · · 2 20:32:22

Two sibling components execute the same key. Watch the network tab: one request. The cache inspector shows both panels subscribed to the single entry; a refetch from either panel updates both. 

<div class="demo-panels">
    <SharedCachePanel Title="Component A"/>
    <SharedCachePanel Title="Component B"/>
</div>

<CacheInspector Keys="@(new[] { DocsKeys.TodoList(5) })"/>

<p class="demo-note">
    Two sibling components execute the same key. Watch the network tab: one request. The cache
    inspector shows both panels subscribed to the single entry; a refetch from either panel
    updates both.
</p>

What to look for#

  • Subscribers: 2 in the cache inspector — both panels observe the same entry.
  • On first load, panel B joins panel A's in-flight fetch: the network tab shows one request for two components.
  • "Refetch from this panel" updates both panels — through the entry, never panel-to-panel. Each panel's query notifies only its own component; the shared entry is the multicast point.
  • Each refetch bumps both render counters — but so would any shared-data design; the isolation demo shows the counters standing still.