Dexie 4.0 Road Map

[dfahlander]

Starting a thread here to discuss or give feedback on the Dexie 4.0 road map.

[dfahlander]

Master branch is now reflecting Dexie 4.0 (since december 14).

The 3.x releases are continued to be maintained on master-3.

[gotjoshua]

I am very stoked to see dexie 4 developing. The decision to allow class mappings that include methods and easily get an injected db ref sounds wicked.

Are there any plans to improve the data that is included on transactions and in middleware mutate calls? I am disappointed that often put operations don't included the keys, for example.

[dfahlander]

I could expose helper functions I use from my middlewares that can get the effective keys of put and add operations, but currently they are internal. I usually do:

const keys = req.keys || getEffectiveKeys(downTable.schema.primaryKey, req);

export function getEffectiveKeys (
  primaryKey: DBCoreIndex,
  req: (Pick<DBCoreAddRequest | DBCorePutRequest, "type" | "values"> & {keys?: any[]}) | Pick<DBCoreDeleteRequest, "keys" | "type">)
{
  if (req.type === 'delete') return req.keys;
  return req.keys || req.values.map(primaryKey.extractKey)
}

I would love to improve the ergonomics of middleware APIs but its not in my top prio right now.

[gotjoshua]

I would love to improve the ergonomics of middleware APIs

#1510

[gotjoshua]

The decision to allow class mappings that include methods and easily get an injected db ref sounds wicked.

I am referring to this section of the road map:
https://dexie.org/roadmap/dexie4.0#distinguish-insert--from-output-types

How far along is the coding on this? (me>=eager : -)

[nlaurie]

Along those lines , PullRequest #1632 splits the roles of returned object and stored entity so no assumptions have to be made on what gets serialized. It's important in scenarios where the objects being served from Dexie are complex object models containing many internal and potential circular references. So the user in these cases just supplies two types the one that gets returned and the one use for serialization. Makes for simpler typing and much less runtime typing compilation issues.

[chapmanjacobd]

I noticed that an alpha build is out for 4.0, does this already include Rich Query support? I'm having trouble converting some of my code from AlaSQL to Dexie.js 3.2.2 -- it looks like 4.0 will make it a lot easier.

when sorting by multiple things how will you handle reverse order for a single property ?

.orderBy(['age desc', 'name'])

.orderBy([dexie.reverse('age'), 'name'])

.orderBy([{key: 'age', order: 'reverse'}, 'name'])

?

[dfahlander]

Hi! Dexie 4.0 alpha does not yet support rich queries. It currently only have the Entity<T> generic available (for dependency injection) and the possibility to distinguish between input and output types by declaring tables as Table<Friend, "id"> instead of Table<Friend, number> (provide the property name instead of its type).

Ordering reverse for one prop only not yet decided on but I lean towards mongodb style:

.orderBy({age: -1, name: 1})

[gotjoshua]

Entity subclasses are not meant to be constructed by application code.

Can we discuss this?

I would love be able to use ts-mixin with Entity...

@dfahlander, any chance this could work one day?

[nlaurie]

My project has many mixins running successfully on the Table Classes and they can be constructed either via Dexie (custom mapClass) or externally. via PullRequest #1632

[barbalex]

I just migrated a WatermelonDB/RX app to dexie. It was generally a great experience. The only downside was: I had to build complex helpers to optimally filter data using indexes when the filters are built dynamically depending on where inside the app a component is used.

For some queries it is currently not possible to use indexes. Which makes parts of the app noticeably slower than they were with WatermelonDB.

Rich queries will make this MUCH easier and faster.

I will soon migrate another app. Am wondering whether to migrate in two steps (1. with helpers, 2. using rich queries) or to wait and migrate directly to using rich queries.

Is there a goal for when to publish version 4.0? Will it likely be weeks, months or years?

Thanks for this great tool!

[dfahlander]

I'm glad to hear you appreciate the library :) Regarding the road map, it will most probably be delayed some months. The current goal is set to December 30th but I wouldn't count on that. I suppose the best shot is to use dexie 4.0 alpha (dexie@next) but implement your own helpers at first to workaround the lack of support for rich queries. By doing it the "old dexie way" you are controlling how you utilize the indexes, which could perform better than the future query planner (as the query planner will have to decide which approach to take in every situation - and in the end - it also has to perform indexedDB queries to accomplish them). If you need guidance for how to write a certain query, please file a stackoverflow question and I'll be glad to help.

[texastoland]

Passerby reading the docs 🙈

I'm not opposed to the new TypeScript syntax:

class AppDB extends Dexie {
  friends = this.Table<{ id: number, name: string, age: number }>('++id, name, age')
}

// alternatively inferred from class?
class AppDB extends Dexie {
  friends = this.Table(Friend, '++id, name, age')
}

const db = new AppDB('dbName')

But I suspect the same thing could be achieved with the fluent syntax:

// see https://github.com/sindresorhus/type-fest/blob/main/source/split.d.ts
export const db = new Dexie('dbName').stores<{
  friends: [number, string, number]
}>({
  friends: '++id, name, age'
})

// alternatively inferring id from ++
export const db = new Dexie('dbName').stores<{
  friends: { name: string, age: number }
}>({
  friends: '++id, name, age'
})

[gokaybiz]

I guess we still can't use orderBy and where at the same time.
Richer Queries'd be awesome...

[rupertsworld]

With the new TypeScript API, how do we specify the db version and upgrades?

[dfahlander]

Sorry for late answer. The new API would dynamically assign a version number, so it wouldn't be required to specify it in the code. It would optionally be possible though if needed for upgraders (migrations), but not required anymore.

[AlejandroAkbal]

Love the project!

I was wondering if Dexie is compatible with Vue/Nuxt 3 SSR?
Or does it only work with Svelte?

[dfahlander]

Dexie was originally supposed to work on any browser-based (DOM-based) runtime. However, it was early adjusted to compile and run in Node (you can import "dexie", but unless the IndexedDB API is polyfilled, any query would fail in node). This makes it friendly to SSR environments in general as long as data fetching from dexie isn't performed by any server side code.

liveQuery() is also adjusted to work on SSR environments as long is the returned observable isn't subscribed to server side.

I haven't tested Nuxt 3 SSR specifically but any feedback is more than welcome. If an issue is found, please file it together with a nice repro and I'll be happy to debug and fix it. We used to have a bit bad SSR experience with nextjs + useLiveQuery() in earlier versions that could be reproduced and fixed so that devs don't need to do various hacks to disable code from executing on the server.