Releases: dexie/Dexie.js
Dexie v3.1.0-beta.13
Dexie 3.1.0-beta.12
Fix #1236 - problems updating FileSystemFileHandle properties.
Dexie v3.1.0-beta.11
This release is just to mark the change of status from alpha to beta.
Will soon take a next step and release a version with stable state (to get useLiveQuery()
out in the stable release).
Just need to take a decision on how to export { liveQuery } directly from dexie or via a new library.
See PR #1244. It would be best to avoid releasing a stable before letting #1244 be committed to avoid API changes.
Dexie v3.1.0-alpha.10
This fix is highly recommended for all 3.1.0-alpha.x users as it contains the important fix for #1268.
Typing corrections
Fix version signatures (PR #1287)
Fixed bugs
#1268 Maximum call stack size exceeded (a bug introduced in Dexie 3.1.0-alpha.x)
#1280 Cannot add CryptoKeys to table with auto-incrementing primary key
Dexie v3.1.0-alpha.9
Bugfixes:
- liveQuery() / useLiveQuery(): Adding new object with indexed prop of the number 0 would not trigger observers even if zero is in the observed range. commit
- liveQuery() / useLiveQuery(): Support for multiEntry indices. PR #1242
- Dexie.getDatabaseNames(): Small optimization for our workaround for non-chromium browsers lacking the IDBFactory.databases(). commit.
Dexie v3.1.0-alpha.8
- Bugfix: bulk requests did not wake up index based liveQuery observers in all scenarios #1225 (comment)
Dexie v3.1.0-alpha.7
v3.1.0-alpha.6
Two bugfixes:
- liveQuery() and useLiveQuery() didn't react correctly when using above()/below() queries. (Direct commit: 7c8f888)
- #1195 The 'update' crud-hook interpreted array properties as object with number keys.
To install:
npm i [email protected]
Dexie v3.1.0-alpha.5
Improved liveQuery
liveQuery()
was explained in this blog post some weeks before this release.
The new liveQuery()
and the corresponding react hook useLiveQuery()
have been improved using a Btree structure to track and match queried ranges against mutated ranges on primary keys and indices.
This release improves liveQuery()
in the following ways:
-
Live queries are more fine-grained. In previous version, index-based queries where always rerun on any mutation. Only primary key based queries were selectively re-run. In this version, index based queries only re-run when the mutation would affect the result of that query.
// The following query will emit new results when todoItems on that todoList are updated. // ...but not if a todo item on another list is updated. // ...but if a todo item is moved into our out from the list, the query will also emit new result. liveQuery(()=> db.todoItems.where({todoListId: todoList.id}).toArray()) // The following query will emit new results when friends within the age range are updated. // ...but not if a friend outside the range is updated. // ...but if a friend's age is changes (moved into range or out from range), it will also emit result. liveQuery(()=> db.friends.where('age').between(20, 20).toArray()) // Key-only queries will not emit new results for property updates - only when key is change liveQuery(() => db.friends.where('age').between(20,30).keys()) liveQuery(() => db.friends.where('age').between(20,30).primaryKeys())
count() requests may still need to emit more often on Table.put() and Table.delete() operations as we cannot detect affected keys unless the mutation is a Table.add(), Table.update() or Collection.modify(), which gives more information to DBCore about the index values of the previous object in database.
-
Rx compatible (via Rx.from()).
import * as Rx from "rxjs"; import { map } from "rxjs/operators"; import { liveQuery } from "dexie"; const observable = Rx.from(liveQuery( () => db.friends.count() )).pipe( map(friendCount => friendCount + 1) );
Also
- Code cleanup and optimizations.
- Option
{allKeys: true}
to bulkPut() and bulkAdd() will be equally fast as not providing that option. - PR 1104: dbName follows dependencies.indexedDB (II)
Dexie v3.1.0-alpha.4
Observability broadcasted between tabs and workers
This version broadcasts txcommitted events between tabs and workers within same origin. It does so using BroadcastChannel so that not only tabs/windows are involved but also workers. This makes the built-in observability in Dexie a nice replacement for dexie-observable addon - and better, as that addon doesnt support workers, you will probably not need the dexie-observable addon anymore unless you use it as a base for dexie-syncable. Note also that dexie-observable slows down write performance a lot while the new built-in liveQuery feature does not.
Any part of an origin (a tab, a frame, a window, a web worker, shared worker or service worker) can observe the database no matter where the database was modified. Any thread can be either producer or consumer. If one peer writes to a Dexie instance, the other part can subscribe and get notified when something change.
Sparing DOM resources
Hidden tabs and minimized windows are not being bothered. Instead they get notified when they are visible again - with an accumulated result so nothing that had happened while being asleep will get lost.
Fallback to storage-event
The implementation falls back to using storage event and localStorage if browser doesnt support BroadcastChannel (Safari). The fallback implementation does only propagate changes across windows/tabs - not workers. It would however possible to make a standalone polyfill for BroadcastChannel that would support this for workers also. I currently don't know of any such polyfill except broadcastchannel-polyfill that currently not supports workers either. If I will have time I may complement it to support all kinds of workers as well as the structuring cloning.
Example
Worker
importScripts("https://unpkg.com/[email protected]");
const db = new Dexie('mydb');
db.version(1).stores({
logItems: '++id'
});
// Write to DB now and then...
setInterval (()=>{
db.logItems.add({foo: "bar", time: new Date()});
}, 1000);
Browser
import React from "react";
import Dexie from "dexie";
import { useLiveQuery } from "dexie-react-hooks";
const db = new Dexie('mydb');
db.version(1).stores({
logItems: '++id'
});
function LogWatcherComponent({limit = 50}) {
// Observe the last {limit} items in log:
const logItems = useLiveQuery(
() => db.logItems.reverse().limit(limit).toArray()
);
return <div>
<h1>Log viewer</h1>
<ul>
{logItems.map(logItem => <li key={logItem.id}>
{logItem.time.toLocaleTimeString()} {logItem.foo}
</li>)}
</ul>
</div>;
}
Read more?
Awesome React integration coming (Blog post)