@FilterableField
The FilterableField is very similar to the Field from TypeGraphQL, however it allows you to specify the fields that should be filterable when querying.
If you use the @nestjs/graphql
Field decorator it will not be exposed in the query type for the DTO.Options
In addition to the normal field options you can also specify the following options-
allowedComparisons- An array of allowed comparisons. You can use this option to allow a subset of filter comparisons when querying through graphql.- This option is useful if the field is expensive to query on for certain operators, or your data source supports a limited set of comparisons.
-
filterRequired- When set totruethe field will be required whenever afilteris used. Thefilterrequirement applies to allread,update, anddeleteendpoints that use afilter.- The
filterRequiredoption is useful when your entity has an index that requires a subset of fields to be used to provide certain level of query performance. - NOTE: When a field is a required in a filter the default
filteroption is ignored.
- The
-
filterOnly- When set totrue, the field will only appear asfilterbut isn’t included as field inside theObjectType.- This option is useful if you want to filter on foreign keys without resolving the relation but you don’t want to have the foreign key show up as field in your query type for the DTO. This might be especially useful for federated relations
Example
In the following example we allowid, title, and completed to be used in queries.
todo-item.dto.ts
Example - allowedComparisons
In the following example theallowedComparisons option is demonstrated by restricting the comparisons that are allowed when filtering on certain fields.
For the id field only eq, neq, in, and notIn comparisons will be exposed in the schema.
The title field will only allow eq, like, and notLike.
todo-item.dto.ts
Example - filterRequired
In the following example thefilterRequired option is applied to the completed field, ensuring that all endpoints that use a filter will require a comparison on the completed field.
todo-item.dto.ts
Example - filterOnly
In the following example thefilterOnly option is applied to the assigneeId field, which makes a query filterable by the id of an assigned user but won’t return the assigneeId as field.
todo-item.dto.ts
@IDField
By default nestjs-query uses the default graphql ID scalar, if you need to use a different graphql scalar type you can use @IDField decorator. nestjs-query will use that scalar type passed to the @IDField for all auto-generated query and mutation endpoints that rely on an input for the id (e.g. findById, updateOne, deleteOne).
The
@IDField uses the same options as @FilterableField.You may have seen
@IDField in various examples throughout the docs, this is because we recommend using @IDField by default.
In the future if you need to change the type later on it should be a trivial change to find all fields that use the @IDField
decorator to update.If you are using Notice the last two lines of code.
query-typegoosethere is a known “won’t fix” bug with class-transformer, where ObjectIds end up getting new values, instead of the hex value they should be. To remedy this, we have a special decorator called ‘@ObjectId`. So, DTO’s should use this as follow:Example
A common use case is to obscure an auto-incremented primary key. In this example we’ll do a simple version of that by declaring a newID scalar that will base64 encode all ids.
common/custom-id.scalar.ts
CustomID scalar with nestjs.
common/common.module.ts
CustomIDScalar is registered you can use it in your DTOS.
todo-item/dto/todo-item.dto.ts
graphql endpoints that need to use an id to query or mutate a TodoItem will use the CustomIDScalar type for the input.
Example - Disable Filtering
If you want to disable filtering and sorting on theid field you can use the disableFilter option.
todo-item/dto/todo-item.dto.ts
@QueryOptions
The @QueryOptions decorator can be used to override any defaults for querying functionality such as sorting, filtering, paging strategy, etc.
Setting a default Filter
When querying the defaultfilter is empty. You can specify a default filter by using the QueryOptions decorator on your DTO option.
The default filter is only used when a filter is not provided in a query.
completed IS TRUE.
todo-item.dto.ts
Result Page Size
By default all results will be limited to 10 records. To override the default you can override the default page size by setting thedefaultResultSize option.
In this example we specify the defaultResultSize to 5 which means if a page size is not specified 5 results will be returned.
todo-item.dto.ts
Limiting Results Size
By default the max number records that can be returned is50.
To override the default you can override the following options specifying the maxResultSize option.
You can disable
maxResultSize by setting the option to -1.Paging Strategy
By defaultnestjs-query uses a cursor based paging strategy and returns a connection for all query many endpoints.
For a more in-depth overview of paging check out the paging docs
You can override the default pagingStrategy to one of the following alternatives
OFFSET- sets paging to allowlimitandoffsetfields, and returns anOffsetConnection.NONE- turn off all paging and always return anArrayConnection.
OFFSET strategy your paging arguments for a many query will accept a limit and/or offset. This will also change the return type from a CursorConnection to an OffsetConnection.
todo-item.dto.ts
NONE pagingStrategy. When using NONE an ArrayConnection will be returned.
todo-item.dto.ts
Paging with Total Count
This section ONLY applies to
CURSOR and OFFSET connections.The
totalCount field is not eagerly fetched. It will only be executed if the field is queried from the client.CURSOR (the default) or OFFSET paging strategy you have the option to expose a totalCount field to allow clients to fetch a total count of records in a connection.
To enable the totalCount field for connections set the enableTotalCount option to true using the @QueryOptions decorator.
todo-item.dto.ts
enableTotalCount to true you will be able to query for totalCount on cursor or offset connections
- GraphQL
- Response
Default Sort
When querying the default is based on the persistence layer. You can override the default by providing thedefaultSort option.
In this example we specify the default sort to be by title.
todo-item.dto.ts
When we use the Note that default value for
@Relation decorator or other relation decorators you might want to define the default sorting criteria like this:todo-item.dto.tsdefaultSort is [], meaning if you do not specify it you will receive the results as determined by your underlying database, which is unreliable and calculated based on how your database engine works.Allowed Boolean Expressions
When filtering you can provideand and or expressions to provide advanced filtering. You can turn off either by using the allowedBooleanExpressions option.
In this example we will only allow and expressions.
todo-item.dto.ts
allowedBooleanExpressions to an empty array. This is useful if you only allow filtering on certain fields and you want to disable all complex filtering.
In this example we will only allow eq comparisons on the id field and disable all and/or boolean expressions.
todo-item.dto.ts
Generated filter-type depth
When querying the default filter is one level deep. You can specify the generated filter-type depth by using thefilterDepth option.
n-levels deep
To generate a filter-type that is n-levels deep you can set the filterDepth option to n. Each level will be generated as a new input type with the name from the previous level as a prefix. In the following example it would generate TodoItemFilter, TodoItemFilterSubTaskFilter and TodoItemFilterTagFilter.
todo-item.dto.ts
infinite depth
To generate a filter-type with infinite depth you can set thefilterDepth option to Number.POSITIVE_INFINITY.
This will generate flat filter-types for each related entity. In the following example it would generate TodoItemDeepFilter, SubTaskDeepFilter and TagDeepFilter.
todo-item.dto.ts