(ctx: RequestContext, options?: ListQueryOptions<Collection> & { topLevelOnly?: boolean }, relations?: RelationPaths<Collection>) => Promise<PaginatedList<Translated<Collection>>>(ctx: RequestContext, collectionId: ID, relations?: RelationPaths<Collection>) => Promise<Translated<Collection> | undefined>(ctx: RequestContext, ids: ID[], relations?: RelationPaths<Collection>) => Promise<Array<Translated<Collection>>>(ctx: RequestContext, slug: string, relations?: RelationPaths<Collection>) => Promise<Translated<Collection> | undefined>(ctx: RequestContext) => ConfigurableOperationDefinition[]Returns all configured CollectionFilters, as specified by the CatalogOptions.
(ctx: RequestContext, collectionId: ID) => Promise<Collection | undefined>(ctx: RequestContext, collectionId: ID) => Promise<Collection[]>Returns all child Collections of the Collection with the given id.
(ctx: RequestContext, collectionIds: ID[]) => Promise<Map<ID, number>>Returns a Map of collection IDs to their product variant counts. This performs a single bulk query to get counts for all provided collection IDs, avoiding N+1 query issues when resolving productVariantCount on multiple collections.
(ctx: RequestContext, collection: Collection) => Promise<Array<{ name: string; id: ID; slug: string }>>Returns an array of name/id pairs representing all ancestor Collections up to the Root Collection.
(ctx: RequestContext, collections: Array<Translated<Collection>>) => Promise<Map<ID, Array<{ name: string; id: ID; slug: string }>>>Returns a Map of collection IDs to their breadcrumb arrays. This performs a bounded number of bulk queries (one per tree level present in the batch, not one per collection), avoiding N+1 query issues when resolving breadcrumbs for multiple collections at once.
(ctx: RequestContext, productId: ID, publicOnly: boolean) => Promise<Array<Translated<Collection>>>Returns all Collections which are associated with the given Product ID.
(ctx: RequestContext, rootId: ID, maxDepth: number = Number.MAX_SAFE_INTEGER) => Promise<Array<Translated<Collection>>>Returns the descendants of a Collection as a flat array. The depth of the traversal can be limited with the maxDepth argument. So to get only the immediate children, set maxDepth = 1.
(collectionId: ID) => Promise<Collection[]>Gets the ancestors of a given collection. Note that since ProductCategories are implemented as an adjacency list, this method will produce more queries the deeper the collection is in the tree.
(collectionId: ID, ctx: RequestContext) => Promise<Array<Translated<Collection>>>(collectionId: ID, ctx?: RequestContext) => Promise<Array<Translated<Collection> | Collection>>(ctx: RequestContext, input: PreviewCollectionVariantsInput, options?: ListQueryOptions<ProductVariant>, relations?: RelationPaths<Collection>) => Promise<PaginatedList<ProductVariant>>(ctx: RequestContext, input: CreateCollectionInput) => Promise<Translated<Collection>>(ctx: RequestContext, input: UpdateCollectionInput) => Promise<Translated<Collection>>(ctx: RequestContext, id: ID) => Promise<DeletionResponse>(ctx: RequestContext, input: MoveCollectionInput) => Promise<Translated<Collection>>Moves a Collection by specifying the parent Collection ID, and an index representing the order amongst its siblings.
(applyAllFiltersOnProductUpdates: boolean) => v3.1.3By default, whenever product data is updated (as determined by subscribing to the ProductEvent and ProductVariantEvent events), the CollectionFilters are re-applied to all Collections.
In certain scenarios, such as when a large number of products are updated at once due to
bulk data import, this can be inefficient. In such cases, you can disable this behaviour
for the duration of the import process by calling this method with false, and then
re-enable it by calling with true.
Afterward, you can call the triggerApplyFiltersJob method to manually re-apply the filters.
(ctx: RequestContext, options?: { collectionIds?: ID[]; applyToChangedVariantsOnly?: boolean }) => v3.1.3Triggers the creation of an apply-collection-filters job which will cause the contents
of the specified collections to be re-evaluated against their filters.
If no collectionIds option is passed, then all collections will be re-evaluated.
If called from within a transaction, the job is not enqueued until that transaction has committed. The returned promise therefore resolves before the job exists, and the job is never enqueued at all if the transaction rolls back. Since the enqueue then happens after the caller has returned, a failure to enqueue cannot be reported back to the caller. It is logged with the ids of the affected collections instead.
(collection: Collection, ctx?: RequestContext) => Promise<ID[]>(ctx: RequestContext, input: AssignCollectionsToChannelInput) => Promise<Array<Translated<Collection>>>Assigns Collections to the specified Channel
(ctx: RequestContext, input: RemoveCollectionsFromChannelInput) => Promise<Array<Translated<Collection>>>Remove Collections from the specified Channel
Architecture reviews, custom plugin work, migrations, ongoing support. Get a hand from the team that builds Vendure.
Talk to the team