Dexie v4.0.1-beta.4

dexie@4.0.1-beta.4

dexie-cloud-addon@4.0.1-beta.53

Fixes #1837 - a bug in dexie-cloud-addon woken up when upgrading dexie to in 4.0.1-beta.2.

Recommended to:

• Upgrade dexie to dexie@4.0.1-beta.4
• Upgrade dexie-cloud-addon to 4.0.1-beta.53

Dexie v4.0.1-beta.3

Replaced by Dexie v4.0.1-beta.4

Dexie v4.0.1-beta.2

Various issues fixed, summary:

• General stability (work around chrome issue + fix dexie issues)
• Vite experience with dexie-react-hooks
• Dexie Cloud developer experience

dexie@4.0.1-beta.2

• Workaround for UnknownError in Chrome (issue #543)
• Dexie 4 optimistic updates are not reverted (issue #1823)
• Fixed "Readwrite transaction in liveQuery context" (issue #1831)
• Correction of Promise.finally (commit 09058ea)

dexie-react-hooks@1.1.7

• Improved vite experience (commit 3ff7d50)
• Improved typing for usePermissions so that it can be used in plain interface typed tables Table (commit 437b697)

dexie-cloud-addon@4.0.1-beta.52

• Fix value of db.cloud.version (did not reveal the version of dexie-cloud-addon)
• Fixen an issue with source map (better debugging experience)
• Export types and helpers needed for customizing built-in OTP authentication (commit 241a76c)

Dexie v4.0.1-beta.1

dexie@4.0.1-beta.1

• Added missing declaration of Dexie.debug: 27ce021
• Bugfix: Support single values compound keys: 93ea5eb
• Bugfix: Provided tx argument to db.transaction() callback would not respect the transaction if db was vip. 2325178
• liveQuery with cache enabled: signal subscribers outside the async context c6b40bd

dexie-cloud-addon@4.0.1-beta.48

• Implementation of the new subscription model https://medium.com/dexie-js/dexie-cloud-subscription-model-cbf9a709ce7
• Updated dexie-cloud-todo-app sample with license eval expiration alert.
• Support for logout API instead of having to delete or clear the database: db.cloud.logout().
• Support for logging in another user without logging out the current one (in db.cloud.login())
• Other fixes and improvements of dexie-cloud-addon.
• Allow expired eval users to pull down data but not to push.
• Treat expired eval users as being forever offline (may still use app but without sync) until they are upgraded to prod by the database admin.
• Remove console logs from the production build.
• Default OTP GUI: Auto-submit OTP when 8 characters are pasted or written.
• Bugfix: Syncing failed if table had inbound compound keys (#1777)
• Handle API-Rate-limits gracefully, avoiding 429 responses by slowing down sync calls when less than 50% of remaining rate-limit are available. 3c4e698
  New dexie-cloud option: disableEagerSync

To install / upgrade:

npm i dexie@next
npm i dexie-cloud-addon@latest

Dexie v4.0.1-alpha.25

PR #1766: Dexie Cloud stuck in login-phase if option {requireAuth: true} was used to db.cloud.configure()

The fix is generic in dexie libary for db.on('ready') callbacks so that the Dexie instance passed to the callback can be used without blocking.

Background:

When the on('ready') callback executes, the ready state shall still not be resolved because any on-ready subscriber's flow is part of making the db ready to resume application queries. But the callback itself need exclusive access before application queries resume - otherwise any db call will block like if it was an application-made db call. This works fine and has been working fine since dexie@2, but has been exclusively based on an async context that spans over the entire flow of db-on-ready callbacks. However, some on-ready callbacks (specifically dexie-cloud's) need to do calls outside of Dexie - such as fetch() calls - those calls will loose the AsyncContext and thus the exclusive access to the db. Therefore, we're now providing a Dexie instance as argument to the on-ready callback - an instance that can call dexie exclusively regardless of the async context. However, a bug prevented this from functioning properly until this release.

Dexie v4.0.0-alpha.24

Fixes #1760: ReadonlyError: Write transactions not allowed within liveQueries

Dexie v4.0.1-alpha.23

Bug fixes

• dexie-cloud-addon: Behave when resetting database without reloading page. c3705a7

• dexie: Fix #1736 Optimistic cache not purged on database deletion

Dexie v4.0.1-alpha.22

General bugfixes

• #1740 Where-clauses with object-syntax fail to reuse virtual indexes - (there's a corresponding fix in the 3.x track)

Bugfixes for cache and optimistic updates

• Unhandled AbortErrors in console log (#1743)
• Improvements of optimistic updates (#1733)
• Move cache-middleware to level 0 (#1744)

Thanks to everyone that tried out 4.0.1-alpha.17 and found the issues that are now fixed!

Dexie v4.0.1-alpha.17

This release replaces 4.0.1-alpha.12, 4.0.1-alpha.13 and 4.0.1-alpha.14 due to issues #1730, #1731 and a few other issues fixed in PR #1733

Cache and Optimistic Updates (v0.1)

The biggest news with this release is the initial support for common cache for live queries that enables multiple liveQuery observables targeting the same set of queries to reuse a single request towards indexedDB and to be immediately triggered as soon as data is being mutated. In practice, this will become a big game changer for large apps that has many ongoing liveQueries going on targeting large amount of data and possibly targeting the same data from different components.

Before the flow was pretty simple but could take some time from a mutation until a change was visible in the app if the app had many components using liveQuery and where the results of the queries were large.

Flow prior to this relase:

1. All live queries for the app is run initially (and the components are rendered).
2. User does som action so that data is being updated (such as db.friends.update(1, {age: 23}).
3. Write-transaction is committed --> onstoragemutated event is broadcasted to all tabs and workers
4. liveQueries that has touched the affected ranges are re-executed. If we have 10 components with affected liveQueries, all 10 of them will simultanously query IndexedDB for their data again.

Flow with this release:

1. All live queries for the app is run initially their promises are immediately cached in memory so that several liveQueries requesting the same data will await the same single promise instead of each one of them requesting indexedDB. When result arrives, the result is kept in the cache as long as there are components subscribing to the query.
2. User does som action so that data is being updated (such as db.friends.update(1, {age: 23}). The cache is immediately recomputed by applying the mutation to the previous result and triggering subscribers immediately to rerender.
3. Mutation promise resolves or reject. If it rejects, the optimistic update is rolled back and components rerender.
4. Transaction commits or rejects. If it rejects, the optimistic updates are rolled back and components rerender. If it was successful, components doesn't need to requery indexedDB because they already have the changes in the cache.
5. All mutations are still broadcasted to other tabs and workers. When a mutation comes from another tab or worker, it will not be optimistic but require a re-execution of the query.

So basically, liveQueries will only request IndexedDB at startup and two identical queries will only result in a single query towards IndexedDB.

Now this is the initial version of this and only certain queries can utilize this:

• If your liveQuery callback explicitely does db.transaction('r', ...), the user expects isolation, so optimistic updates won't be used.
• Only simple range queries are supported in this initial version: equals, above, aboveOrEqual, below, belowOrEqual, between, startsWith.
• Only tables with inbound keys are supported.
• Only toArray() queries (not .keys(), .primaryKeys() or .count())
• Not offset based queries.
• Not ignoreCase queries
• Not anyOf or inAnyRange

Example of optimised queries:

• db.friends.toArray()
• db.friends.where('age').between(18,65, true, true).limit(10).toArray()

Example of non-optimized queries in this initial version:

• db.friends.primaryKeys()
• db.friends.count()
• db.friends.offset(25).toArray()
• db.transaction('r', db.friends, () => db.friends.toArray())

PRs:

• #1718 Optimistic updates
• #1727 Fix optimistic updates

Other changes:

• Dexie will throw if trying to mutate data from a liveQuery callback ( liveQuery(()=>db.friends.add({...})) )
• A new constructor option to Dexie is {cache: 'immutable' | 'cloned' | 'disabled'}. The default is 'cloned' but 'immutable' would give better performance because the cached results can be returned directly to the caller without having to deep clone it. However, the data will be frozen so if the liveQuery callback would try to set properties or call mutating array operations on the results, it will fail to do so if having { cache: 'immutable' }. array.sort() is one example of a commonly used mutable operation. Workaround is to use array.slice().sort() instead.

Other PRs in this release

• #1711 Add .d.mts files to support import types properly.
• #1716 Remove custom unhandledrejection event propagation

Dexie v4.0.1-alpha.14

This release is replaced by 4.0.1-alpha.17