New API for Nano Stores
We split all stores to 2 categories: store (for any store) and map (for key-value object and special helpers to work with keys).
Memory store is a regular store, which keep value in the memory (and do not clean it until page will be closed).
import { memoryStore } from 'nanostores'
let profileCache = memoryStore<Profile>(guestProfile)
Old API: store = createStore(); keepActive(store)
Daemon store is a store with constructor and destructor. It could listen other services (like WebSocket or History API). It has active and disabled mode. On first store’s listener it goes to active mode. On last listener unsubscibring it will be removed from the memory and will lost it’s value.
import { daemonStore } from 'nanostores'
let router = daemonStore<Route>(defaultRoute, () => {
// subscribe to history API
return () => {
// unsubscribe from history API
}
})
import { daemonMap } from 'nanostores'
// For key-value store
Old API: createStore()
Question: maybe “service store” is better than “deamon store”?
Deamon template is a template to create similar map stores. For instance, every User
could be a separated store (useful for CRDT libraries like Logux, where every User
store hides CRDT complixty inside):
import { deamonTemplate } from 'nanostores'
let User = deamonTemplate((store, id, ...args) => {
// connect listsners to WebSocket log and listen for CRDT events
() => {
// remove listener from log
}
})
let user1 = User(id, ...args)
Old API: defineMap()
Good point :(
Hm, I didn’t fully get the point. How “atom” is related to “composable”? Maybe you was confused that I talked about 2 different topics in that comment?
I am planning to use “atom” for stores with some simple variable like:
It has no relationship with
compute
andderived
.It is not very common-used. Rx fans do not need Nano Stores, since they will prefer to continue using Rx.