breeze-client / WhereObject

Type Alias: WhereObject<T>

WhereObject<T> = Entity extends T ? object : { [K in WhereKey<T>]?: K extends "and" | "or" ? readonly (Predicate | WhereObject<T>)[] : K extends "not" ? Predicate | WhereObject<T> : K extends FunctionExpressionPath ? FilterClause<T, any> : K extends CollectionPath<T> ? { [Q in QuantifierOp]?: Predicate | WhereObject<CollectionElement<T, K>> } : FilterClause<T, PropertyValue<T, K>> }

Defined in: src/query/property-path.ts:320

The object - "JSON" - form of a filter, checked against T.

EntityQuery.from(Customer).where({ city: 'London', country: 'UK' });
EntityQuery.from(Order).where({ freight: { gt: 100 } });
EntityQuery.from(Order).where({ 'customer.companyName': { startsWith: 'A' } });
EntityQuery.from(Customer).where({ or: [{ city: 'London' }, { city: 'Berlin' }] });
EntityQuery.from(Customer).where({ orders: { any: { freight: { gt: 100 } } } });

Several keys in one object are and-ed, as the runtime does with them.

This deliberately enumerates the model's paths as keys rather than validating the object the caller wrote. Both check the same mistakes, but only this shape makes a bad key an ordinary excess-property error - which is the diagnostic that carries a spelling suggestion:

Object literal may only specify known properties, but 'compnyName' does not exist
in type '{ ... }'. Did you mean to write 'companyName'?

The cost is that the compiler prints that type in the message, so these are longer than the errors from the three-argument form. It is the better trade: the suggestion names the fix.

object for an untyped query, which restricts nothing - see PropertyPath.

Type Parameters

T

T