jmap-kit
    Preparing search index...

    Type Alias BaseQueryResponseInvocationArgs

    type BaseQueryResponseInvocationArgs = {
        accountId: Id;
        canCalculateChanges: boolean;
        ids: Id[];
        limit: UnsignedInt;
        position: UnsignedInt;
        queryState: string;
        total: UnsignedInt;
    }
    Index

    Properties

    accountId: Id

    The id of the account used for the call.

    canCalculateChanges: boolean

    This is true if the server supports calling Foo/queryChanges with these filter/sort parameters. Note, this does not guarantee that the Foo/queryChanges call will succeed, as it may only be possible for a limited time afterwards due to server internal implementation details.

    ids: Id[]

    The list of ids for each Foo in the query results, starting at the index given by the position argument of this response and continuing until it hits the end of the results or reaches the limit number of ids. If position is >= total, this MUST be the empty list.

    (if set by the server) The limit enforced by the server on the maximum number of results to return. This is only returned if the server set a limit or used a different limit than that given in the request.

    position: UnsignedInt

    The zero-based index of the first result in the ids array within the complete list of query results. If the ids array is empty, the value is undefined and MUST NOT be used by the client.

    queryState: string

    A string encoding the current state of the query on the server. This string MUST change if the results of the query (i.e., the matching ids and their sort order) have changed. The queryState string MAY change if something has changed on the server, which means the results may have changed but the server doesn’t know for sure.

    The queryState string only represents the ordered list of ids that match the particular query (including its sort/filter). There is no requirement for it to change if a property on an object matching the query changes but the query results are unaffected (indeed, it is more efficient if the queryState string does not change in this case). The queryState string only has meaning when compared to future responses to a query with the same type/sort/filter or when used with /queryChanges to fetch changes.

    Should a client receive back a response with a different queryState string to a previous call, it MUST either throw away the currently cached query and fetch it again (note, this does not require fetching the records again, just the list of ids) or call Foo/queryChanges to get the difference.

    (only if requested) The total number of Foos in the results (given the filter). This argument MUST be omitted if the calculateTotal request argument is not true.