Suggestion for attribute value:

Error for incorrect type:

Updated playground link: https://tsplay.dev/WYQJzW

Would it be possible to even infer the type from the listDocuments as well?

Would it be possible to even infer the type from the listDocuments as well?

Could you explain what you mean? I don't think its possible to infer the type returned by listDocuments.

Would it be possible to even infer the type from the listDocuments as well?

Could you explain what you mean? I don't think its possible to infer the type returned by listDocuments.

I think this is what @TorstenDittmann meant: TS playground

You'll see I added a listDocuments, that checks if the return type from Query.isNull is valid, without having to pass the type to Query.isNull.

Doing this for all the query methods would be complicated, but I believe it is possible.

Modifying your example slightly
https://tsplay.dev/wXr2Dm
provides autocomplete and type validation for attribute parameter. However, I cant think of a way of enforce type of value parameter.

I think it might not be possible to skip the type when creating a query with list documents, at least not with the current implementation. This is because:

1. Any function signature for listDocuments would only have access to the value returned by Query.* methods. The most type restrictive version of return value of Query.equal is equal(${string & keyof T}, [${string}]). The second parameter has to be string in order to support array of values ie both "hello" and "hello","world". Since, the return type does not depend on type of T[K] it wouldn't influence the second argument to Query.equal and hence no typechecking.
2. Even for functions such as isNull in @TGlide 's example, the type of the generic type extends string instead of T. I couldn't find an implementation that allows using T. Query.equal needs T in order to find type of T[typeof attribute].

I haven't thought this through but I think it might be possible to skip the type by changing the return value of Query.equal. IMO this would be way too complex and totally not worth it.

About 2: Usage outside listDocuments is either

export type QueryStr<T extends ModelType> = Query.isNull<string & keyof T>;
const a: QueryStr<TodoList> = Query.isNull("id")

or

Query.isNull<string & keyof TodoList>("id")

which looks weird to me.

I think it might not be possible to skip the type when creating a query with list documents, at least not with the current implementation. This is because:

1. Any function signature for listDocuments would only have access to the value returned by Query.* methods. The most type restrictive version of return value of Query.equal is `equal(${string & keyof T}, [${string}])`. The second parameter has to be string in order to support array of values ie both `"hello"` and `"hello","world"`. Since, the return type does not depend on type of T[K] it wouldn't influence the second argument to Query.equal and hence no typechecking.

2. Even for functions such as isNull in @TGlide 's example, the type of the generic type extends string instead of T. I couldn't find an implementation that allows using T. Query.equal needs T in order to find type of `T[typeof attribute]`.

I haven't thought this through but I think it might be possible to skip the type by changing the return value of Query.equal. IMO this would be way too complex and totally not worth it.

About 2: Usage outside listDocuments is either

export type QueryStr<T extends ModelType> = Query.isNull<string & keyof T>;
const a: QueryStr<TodoList> = Query.isNull("id")

or

Query.isNull<string & keyof TodoList>("id")

which looks weird to me.

I also thought about changing the return types, would be way easier to infer types. But would change how listDocuments works.

@TorstenDittmann thoughts?

For now I don't think we should change the return type of Query.

@TorstenDittmann, what do you think of #655 (comment)?

Anything new on this one?

It would be very great if we can merge this PR ^^

Anyone can review it ?

🙏