`.where()` haven't strict parameters types

[cawa-93]

Several methods (such as add or put) have strict types for parameters

https://github.com/dexie/Dexie.js/blob/b027b1bdb28fc32cc2d1ff8b95a3de4ba8798207/src/public/types/table.d.ts#L45

Because of this, Typescript provides hints when typing, and highlights errors

But several methods like where doesn't provide strict parameter types https://github.com/dexie/Dexie.js/blob/b027b1bdb28fc32cc2d1ff8b95a3de4ba8798207/src/public/types/table.d.ts#L24-L25

As the result, you do not receive any autocomplete suggestions or error messages:

playground

[spion]

I created a package trying to fix this here https://github.com/spion/dexie-better-types

A separate package should make it easier to progressively polish the types in case I got something wrong. I'll also be dogfooding them on a bunch of new code soon.

Feel free to try them out and report in case something is missing. Once all potential issues are ironed out, I'd be happy to send a PR in this repo (or even now if the dexie maintainers would prefer that approach)

[dfahlander]

Thanks for this nice iniative! I hope it can help input to how we could incorporate better typings in dexie's where clauses. I did perform a step in this direction with Table.update() in dexie@4, expecting an UpdateSpec using a map between KeyPaths and KeyPathValue types.

When the repo feels solid, we could incorporate it into dexie again. Any feedback on this project from other users are much welcome!

[paulo-assoc]

Hi @dfahlander Was a pull request ever created or accepted which adds strict parameter types to .Where? Lack of this is the only thing holding me back from using the very nice package Dexie.

[dfahlander]

There was no PR created. A PR would be much welcome in the src/public/types/table.d.ts.

The where-clause must support the following:

• Support loose typing (do not enforce anything) if the table is typed with any (Table<any, any>)
• Support for the following formats:
  • db.table.where('prop').equals(x)
  • db.table.where('prop.subprop').equals(x)
  • db.table.where({prop: x})
  • db.table.where({"prop.subprop": x})
  • db.table.where('[prop1+prop2]').between(["foo", 1], ["foo", 100])
  • db.table.where('[propA+propB+propC]').equals(["foo", 1, "x"])

Have a look at how UpdateSpec is declared using the KeyPaths<T> generic that uncollapses all possible keypaths given an object tree.

Even though the runtime currently only support checking for indexed properties, the typings are hard to catch from the schema declaration so we still need to respect the typed tables rather than schema declaration. dexie@5's richer queries is planned to support querying on non-indexed properties anyway so this PR would survive that and we could extend the value with operators there when needed, a bit like UpdateSpec has been extended with PropModification operator.

[paulo-assoc]

Thanks, @dfahlander!

@spion Were you going to submit a pull request based on your nice dexie-better-types repo?

[spion]

@posterhoudt I've not had much feedback on the types so far. They work pretty great for me. I can try and check if they need some updates for anything new that has been added since and if not create the PR.

Will need to try and find some time for this though - possibly next week.

Note that its very easy to try that package out. The README outlines the instructions. Just installing the package and swapping the Table type should be sufficient and give you instant feedback if anything in your app breaks in terms of typechecking doing the wrong thing. Would appreciate any feedback from users with larger apps (after all, stricter types can by definition lead to compiler errors :grinning:)

[paulo-assoc]

Thanks, @spion. I will try out your new types and post my feedback here.