@tilia/query·On top of tilia·MIT

Remote Data That Feels Local

A query-state layer on top of tilia. Remembered reads answer immediately while results refresh in the background; writes apply on the spot and sync quietly. No loading wall in front of data the device already has.

Get Started GitHub

sève /sɛv/ n., f. — the sap. Moves between root and crown; held through winter, flowing again at thaw.

Query state

const [claims, store] = make({
  id: (claim) => claim.id,
  matches: (q, claim) => claim.status === q.status,
  store: Store.make({ find, upsert, remove })
})

// remembered now, refreshed quietly
const opened = claims.array({ status: 'open' })

// applies now, syncs quietly
store.upsert({ ...claim, status: 'closed' })

let (claims, store) = TiliaQuery.make({
  id: claim => claim.id,
  matches: (q, claim) => claim.status == q.status,
  store: TiliaQuery.Store.make({find, upsert, remove}),
})

// remembered now, refreshed quietly
let opened = claims.array({status: "open"})

// applies now, syncs quietly
store.upsert({...claim, status: "closed"})

$ npm install @tilia/query

Why @tilia/query

Every feature ends up reinventing the same remote-data flow: load, cache, refresh, merge, survive offline. @tilia/query unifies it into one flow.

1.1

One lifecycle for remote data

Load, remember, refresh, reconcile — every collection moves through the same shared flow, so feature code stays domain code.

1.2

Held through winter

Writes apply instantly; with IndexedDB, the durable outbox survives a restart. Reopen next week and sync resumes where it left off.

1.3

Views keep their identity

Results are memoized id lists: a refetch that changes nothing re-renders nothing, and changed objects move between queries in place — no refetch.