Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Misc] Update dependency dexie to v4 - autoclosed #115

Closed

Conversation

renovate-bot
Copy link
Contributor

@renovate-bot renovate-bot commented Mar 27, 2024

Mend Renovate

This PR contains the following updates:

Package Change Age Adoption Passing Confidence
dexie (source) 3.2.7 -> 4.0.4 age adoption passing confidence

Release Notes

dexie/Dexie.js (dexie)

v4.0.4: Dexie v4.0.4

Compare Source

Fixes #​1955 for real this time (the fix in 4.0.2 wasn't correct enough for npm)

v4.0.3

Compare Source

v4.0.2: Dexie v4.0.2

Compare Source

Patch Release

dexie@4.0.2

  • Fixes issue #​1946 - liveQueries of compound index involving auto-incremented primary key as part failed to update.
  • ~~Fixes issue #​1955 - tsconfig.json in root referering to nonexisting tsconfig in non-bundled src directory.~~ Fixed for real in 4.0.4.

dexie-cloud-addon@4.0.2

  • Allow logging in with demo account in default login GUI and customized login GUI. User can write an imported @​demo.local address in the email dialog and can skip the OTP step.

v4.0.1: Dexie v4.0.1

Compare Source

Dexie 4 Stable

After 3 years is alpha and beta, and a week in RC, Dexie@4 is finally out!

Changed Version Handling (PR #​1880)

  • Dexie@4 accepts upgrading schema WITHOUT incrementing the version number.
  • Dexie@4 is now able to open a previous version of the database without throwing VersionError.

It's still recommended to increment version number when schema has been updated before publishing new versions of an application since it can make opening the db fractions of ms faster. But it's not required.

(If the native version has diverged from the declared version - which happen when extending schema without incrementing version, dexie need to increment the native version to extend schema - and after a page refresh dexie will detect diverged version by catching VersionError and will redo open with the exact installed version under the hood. When measuring the extra time to open an older version in indexedDB and catch VersionError 10,000 times, it only took 1000 ms - 0.1 ms per try (on a macbook pro), so it should be negligible (https://jsfiddle.net/dfahlander/9tg13fwk/19/))

Cache

Non-transactional live queries utilize memory cache to assist in query resolution. It is possible to opt-out from using the cache using the option {cache: 'disabled'}. The cache can greatly improve simple pure range-based live queries and reduce the queries towards IndexedDB by reusing common queries from different components. The cache will be continously developed and optimized further to improve the new paging support in Dexie 5.0.

Workarounds for flaky browsers

Dexie 4 catches various issues in the IndexedDB support for Chrome and Safari. Without dexie@4 transactions and write operations can suddenly fail in modern versions of Chrome and Safari but dexie makes sure to protect the end user from experience any issues. It does this by reopening the database or redoing the transaction when these things happen - all without the developer having to worry about it. See issues #​543 and #​613. (A close upcoming release on the 4.0-track will also address #​1660 and #​1829).

Supports Dexie Cloud

With Dexie 4.0, you can optionally use dexie-cloud-addon and connect your local database with a cloud based database. Dexie Cloud is a complete solution for authorization and synchronization of personal data with support for sharing data between users.

Improved Typing

Dexie 4 has some improved typing. Specifically, Collection.modify() and Table.update() use template literals to suggest code completion and type checking of keypaths to update.

Distinguish insert- from output types

The type passed to db.table.add() can be different from the type returned from db.table.get() and tb.table.toArray(). This mirrors reality better since some properties may be optional when adding (such as an auto-incremented primary key or dexie-cloud properties realmId and owner).

The generic type Table<T, TKey> is extended with a 3rd optional parameter TInsertType making it possible to declare a table as such:

class MyDB extends Dexie {
  friends!: Table<
    { id: number; name: string; age: number }, // T (id is always there)
    number, // TKey (type of primary key)
    { id?: number; name: string; age: number } // TInsertType (id is optional)
  >;
}

A new helper generic EntityTable<T> also exists as a "don't repeat yourself" sugar on top of this, and will also omit any method on the type. In case the type is a mapped class with helper methods, you are still able to pass simple POJO objects
to add() and put() with only data properties.

interface Friend {
  id: number;
  name: string;
  age: number;
}

class MyDB extends Dexie {
  friends!: EntityTable<Friend, 'id'>; // Automatically makes `id` optional when adding and picks its TKey type.
}

If using Dexie Cloud, there's a DexieCloudTable<T> generic that will declare the implicit Dexie Cloud properties on the entity correctly for insert- and output types:

interface Friend {
  id: string;
  name: string;
  age: number;
  realmId: string;
  owner: string;
}

class MyDexieCloudDB extends Dexie {
  friends!: DexieCloudTable<Friend, 'id'>; // Makes id, realmId and owner optional on insert operations.
}
A solution to dependency issues with mapped classes

In dexie 3, a mapped class that needs to access the database from its methods, will needs to access the a db instance. But it is a bit awkward to tie a method body to the same instance exported from the db module. For example, having two instances of db with different constructor parameters would not work as both would use one of the instances from their method bodies.

In Dexie 4.0, this is solved using a lightweight dependency injection. There is a generic class Entity that your classes may extend from in order to get your database instance injected as a protected property db on every entity instance. Your class methods can then perform queries onto the db without being dependant on the db module of your app. This use case will require a subclassed Dexie declaration though. There will still be cyclic import dependencies but only on the type level.

export class Friend extends Entity<AppDB> {
  id!: number;
  name!: string;
  age!: number;

  async birthday() {
    return await this.db.friends.update(this.id, (friend) => ++friend.age);
  }
}

Breaking Changes

No IE11 support

No support for Internet Explorer 11, legacy Edge (non-chromium) nor legacy Safari below version 14.


Configuration

📅 Schedule: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined).

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about this update again.


  • If you want to rebase/retry this PR, check this box

This PR has been generated by Mend Renovate. View repository job log here.

@renovate-bot renovate-bot changed the title Update dependency dexie to v4 [Misc] Update dependency dexie to v4 Apr 2, 2024
@renovate-bot renovate-bot force-pushed the renovate/dexie-4.x branch 2 times, most recently from 1518c62 to 7db1486 Compare April 10, 2024 18:07
@renovate-bot renovate-bot force-pushed the renovate/dexie-4.x branch 2 times, most recently from ec20832 to 56d72a4 Compare April 19, 2024 09:49
@renovate-bot renovate-bot changed the title [Misc] Update dependency dexie to v4 [Misc] Update dependency dexie to v4 - autoclosed May 6, 2024
@renovate-bot renovate-bot deleted the renovate/dexie-4.x branch May 6, 2024 14:28
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
1 participant