Ingestion Strategies

COLLECTION_ALL ingestion

For a bounded array fetched entirely — the default ingestion type in Flux, and the right choice whenever a collection is small enough to cache and dispatch as one complete payload rather than paginating or evicting it.

Prerequisites
  • A store already registered via register() — see api/register
  • ingestion/snapshot for the single-object counterpart, ingestion/lru for anything too large to fetch in full
1

Basic usage

Set ingestionType: 'COLLECTION_ALL' — or simply omit ingestionType entirely, since this is the default.
typescript
1flux.register({
2  store: useServicesStore,
3  channel: 'services',
4  event: 'UPDATE',
5  idbKey: 'services:all',
6  ttl: 'medium',
7  ingestionType: 'COLLECTION_ALL',
8  hydrateState: (store, data) => store.getState().setServices(data),
9})
2

What qualifies as COLLECTION_ALL

Any array you're comfortable fetching, caching, and re-dispatching in full every time — a services list, a team roster, a pricing table. Not something you'd paginate or cap by size.
typescript
1// COLLECTION_ALL is for a bounded array — small enough to fetch,
2// cache, and dispatch as one complete payload every time.
3 
4flux.register({ channel: 'services', ingestionType: 'COLLECTION_ALL', /* ... */ })
5flux.register({ channel: 'team', ingestionType: 'COLLECTION_ALL', /* ... */ })
6flux.register({ channel: 'pricing', ingestionType: 'COLLECTION_ALL', /* ... */ })
7 
8// It's also the default — omitting ingestionType entirely behaves
9// as COLLECTION_ALL, so set it explicitly if you actually mean SNAPSHOT.
3

Shape validation

Because the whole point of this type is a bounded array, Flux checks for one on dispatch.
typescript
1// dispatchToStore validates the payload shape for this type:
2// an array is expected. Receiving an object instead logs a warning
3// rather than silently dispatching the wrong shape into your store.
4

How it's cached

COLLECTION_ALL shares the same simple storage model as SNAPSHOT — the full array goes into one envelope under the channel's idbKey, with none of the per-item key splitting LRU channels use.
typescript
1// Like SNAPSHOT, the entire array is written as one TTL envelope
2// under the full idbKey — no per-item splitting, no LRU eviction
3// machinery.
4 
5// { data: [...], cachedAt: <timestamp>, ttl: <resolved ms> }
6// stored at 'global:services:all' (or 'user:{userId}:...' if scoped)
5

diffBeforeUpdate

Skips dispatching entirely if the incoming array matches what's already cached — useful when a realtime channel fires more often than the underlying data actually changes.
typescript
1// diffBeforeUpdate compares the incoming array against what's
2// already cached, and skips the dispatch entirely if nothing changed —
3// useful for channels that fire realtime events more often than the
4// data actually changes.
5 
6flux.register({
7  channel: 'pricing',
8  ingestionType: 'COLLECTION_ALL',
9  diffBeforeUpdate: true,
10  /* ... */
11})
12 
13// Note: this option should be omitted on multi-chunk Stunk
14// registrations — see state_managers/stunk (or the relevant
15// state-manager adapter doc) for why.
6

An open question worth confirming: partial realtime updates

The documented realtime contract (FluxNormalizedEvent) carries one entity per event — an id, an op (CREATE/UPDATE/DELETE), and that single row's data. The spec doesn't lay out how a single-row event is reconciled into a COLLECTION_ALL channel's full array on dispatch — whether Flux merges the row into the cached array internally, or whether the array shape validation in step 3 means a single-row event would actually warn.
Flagging this rather than guessing

Rather than invent a merge algorithm the source material doesn't describe, onRealtimeUpdate is the documented, safe place to handle a single-row event yourself if you need array-level reconciliation — worth confirming the exact built-in behavior against the actual dispatchToStore implementation before this section is finalized.

Atomic Replacement Guarantee

Because COLLECTION_ALL writes are atomic within IndexedDB, the entire array is replaced in a single transaction. Subscribers receive the updated collection intact without intermediate empty states or partial arrays during hydration.

For single-object channels, see ingestion/snapshot. For collections too large to fetch in full, see ingestion/lru. For ingestionType alongside the rest of a registration, see api/register.

Powered by Flux