Changelog for @signaldb/sync
[2.0.0] - 2026-10-27
BREAKING CHANGES
- Removed compatibility with
@signaldb/coreversions below2.0.0 - Removed
persistenceAdapteroption fromSyncManagerconstructor options. UsedataAdapteroption instead. - Without an
id, the sync manager's own collections are now nameddefault-sync-manager-changes,default-sync-manager-snapshotsanddefault-sync-manager-sync-operations. They used to be namedundefined-changesand so on, because the names were built from theidoption rather than from its default. If you persisted the sync manager's data without settingid, the changes not yet pushed and the snapshots under the old names are no longer read: either setid: 'undefined'to keep the old names, or let the next sync rebuild the snapshots. With@signaldb/indexeddb, rename the stores in yourschemaaccordingly.
Added
isSyncing(name, true)returns aPromise<boolean>and reads the active sync operations through an{ async: true }query. Use it when the sync manager'sdataAdaptercannot answer a query on the spot, such as anAsyncDataAdapteror aWorkerDataAdapter.isSyncing(name)stays synchronous and reactive.
Changed
addCollectionis generic over the item type of the collection passed to it, so a collection whose item type extends the sync manager's item type can be added without a cast.
Fixed
sync()rejects for a collection whose stored data could not be loaded, andisReady()rejects when the sync manager's own collections could not be loaded. Both used to proceed as if the data had been loaded, so a sync could compute its changes against an empty collection.isReady()resolves only once the sync manager's own collections are ready. It resolved immediately, so a sync could start before the stored changes and snapshots had been loaded.- Remote changes delivered with data through
registerRemoteChangeare applied in the collection's sync queue. They could previously run at the same time as a sync of the same collection and interleave with it.
[1.3.1] - 2025-04-29
Fixed
- Fix
computeChangesmethod to work with items that have null values
[1.3.0] - 2025-04-24
Added
- Added
rawChangesarray topushfunction parameters to make all changes available during push. - Added
modifiedFieldstochangesobject onpushto allow patch updates
[1.2.2] - 2025-03-20
Fixed
- Fix version for
@signaldb/coredependency
[1.2.1] - 2025-03-19
Changed
- Use upserts in
updateOneinternally instead of searching for the document first
Fixed
- Use
replaceOneinternally to replace documents in collections instead of just updating them withupdateOne
[1.2.0] - 2025-03-10
Added
- Allow configuration of debounce time for pushing changes (thanks @augustpemberton!)
Fixed
- Don't skip debounces when pushing multiple collections (#1470, thanks @augustpemberton!)
[1.1.3] - 2025-02-19
Changed
- Improved sync performance by reducing overhead in internal
applyChangesmethod - Improved sync performance by updating only changed documents when applying snapshots
[1.1.2] - 2025-02-18
Changed
- Add indices to internal collections to improve performance
[1.1.1] - 2025-01-21
Fixed
- Explicitly turn of reactivity for internal queries
[1.1.0] - 2025-01-13
Fixed
- Wait until collections persistence was initialized before starting sync
Added
- Allow sync to be paused and resumed with
syncManager.startSync(name)andsyncManager.pauseSync(name)(thanks @obedm503) - Added
syncManager.startAll()andsyncManasger.pauseAll()to start and pause all collections
[1.0.1] - 2025-01-10
Changed
- Define names for internal collections
- Dispose temporary collections in applyChanges function
[1.0.0] - 2024-12-16
Changed
- BREAKING:
SyncManagerdoes now default to no persistence instead oflocalStorage