Skip to content

Releases: dexie/Dexie.js

Dexie v3.1.0-beta.13

07 Jun 11:35
Compare
Choose a tag to compare
Dexie v3.1.0-beta.13 Pre-release
Pre-release

Bugfix: Transaction.abort() does not rollback changes (filed as a repro PR in #1329)

Dexie 3.1.0-beta.12

03 Jun 10:52
Compare
Choose a tag to compare
Dexie 3.1.0-beta.12 Pre-release
Pre-release

Fix #1236 - problems updating FileSystemFileHandle properties.

Dexie v3.1.0-beta.11

28 May 10:58
Compare
Choose a tag to compare
Dexie v3.1.0-beta.11 Pre-release
Pre-release

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

28 Apr 22:26
Compare
Choose a tag to compare
Dexie v3.1.0-alpha.10 Pre-release
Pre-release

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

18 Mar 09:15
Compare
Choose a tag to compare
Dexie v3.1.0-alpha.9 Pre-release
Pre-release

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

12 Feb 07:00
Compare
Choose a tag to compare
Dexie v3.1.0-alpha.8 Pre-release
Pre-release
  • Bugfix: bulk requests did not wake up index based liveQuery observers in all scenarios #1225 (comment)

Dexie v3.1.0-alpha.7

10 Feb 10:08
Compare
Choose a tag to compare
Dexie v3.1.0-alpha.7 Pre-release
Pre-release
  • Bugfix: put-requests did not wake up index based liveQuery observers #1225
  • BulkError: Possible to track individual errors. Add failuresByPos property: #1209
  • Expose IDB 'close' event: #1212

v3.1.0-alpha.6

18 Dec 13:06
Compare
Choose a tag to compare
v3.1.0-alpha.6 Pre-release
Pre-release

Two bugfixes:

To install:

Dexie v3.1.0-alpha.5

16 Dec 16:54
Compare
Choose a tag to compare
Dexie v3.1.0-alpha.5 Pre-release
Pre-release

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

25 Nov 12:57
Compare
Choose a tag to compare
Dexie v3.1.0-alpha.4 Pre-release
Pre-release

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)

Stackblitz playground