import { IMetadataProvider } from '@memberjunction/core';
import { MJListEntity } from '@memberjunction/core-entities';
import { Observable } from 'rxjs';
import * as i0 from "@angular/core";
/**
 * Describes one operand for the Venn / set-op pipeline. The component
 * passes these in instead of raw `MJListEntity`s now that views are
 * supported; the service handles cache-keying + record-ID resolution.
 */
export interface SetOperand {
    kind: OperandKind;
    /** ID of the underlying MJ List or MJ User View. */
    id: string;
    /** Display name shown in the Venn legend + selection chips. */
    name: string;
    /** Entity ID — used to enforce the same-entity invariant on operations. */
    entityID: string;
    /** Entity name — denormalized for display. */
    entityName: string;
    /** Hex color from the predefined palette; chosen by the component. */
    color: string;
}
/**
 * Discriminates a Venn set / set-op operand between a saved MJ List and a
 * User View. The Venn diagram uses this to render views with a dashed
 * stroke (per mockup 10) so users can tell at a glance which inputs are
 * static (lists) vs. dynamic-at-resolution (views).
 */
export type OperandKind = 'list' | 'view';
/**
 * Stable key for an operand across cache lookups + state persistence.
 * `list:<id>` and `view:<id>` deliberately namespace the ID so a view and
 * a list with the same UUID (extremely unlikely but possible) can't
 * collide in the cache.
 */
export declare function OperandCacheKey(kind: OperandKind, id: string): string;
/**
 * Represents a set (list or view) in the Venn diagram
 */
export interface VennSet {
    /** Stable cache key. Use `OperandCacheKey()` to construct. */
    operandKey: string;
    /** Discriminator — drives the dashed-vs-solid stroke in the Venn diagram. */
    kind: OperandKind;
    /** Underlying list / view ID. Same UUID space as the entity it points at. */
    listId: string;
    listName: string;
    color: string;
    recordIds: Set<string>;
    size: number;
}
/**
 * Represents an intersection region in the Venn diagram
 */
export interface VennIntersection {
    /**
     * IDs of lists that participate in this intersection
     */
    setIds: string[];
    /**
     * Labels of lists that participate in this intersection
     */
    setLabels: string[];
    /**
     * Number of records in this intersection
     */
    size: number;
    /**
     * Actual record IDs in this intersection
     */
    recordIds: string[];
    /**
     * Display label for this region
     */
    label: string;
    /**
     * Whether this region is currently selected
     */
    isSelected: boolean;
}
/**
 * Complete Venn data for visualization
 */
export interface VennData {
    sets: VennSet[];
    intersections: VennIntersection[];
    entityId?: string;
    entityName?: string;
}
/**
 * Set operation types
 */
export type SetOperation = 'union' | 'intersection' | 'difference' | 'symmetric_difference' | 'complement';
/**
 * Result of a set operation
 */
export interface SetOperationResult {
    operation: SetOperation;
    inputSetIds: string[];
    resultRecordIds: string[];
    resultCount: number;
}
/**
 * Service for performing set operations on lists and preparing data for Venn visualization.
 */
export declare class ListSetOperationsService {
    private _provider;
    /** Set the metadata provider this service should use. Components should call this after injection. */
    set Provider(value: IMetadataProvider | null);
    get Provider(): IMetadataProvider;
    private loadingSubject;
    loading$: Observable<boolean>;
    private listDetailsCache;
    constructor();
    /**
     * Load list data and calculate all intersections for Venn visualization
     */
    calculateVennData(lists: MJListEntity[]): Promise<VennData>;
    /**
     * Generalized Venn-data loader supporting both lists and views.
     *
     * - Lists resolve via the same `MJ: List Details` query as the legacy
     *   path (cached by `list:<id>`).
     * - Views resolve via `RunView({ViewID})` and primary-key serialization;
     *   cached by `view:<id>` so picking the same view twice doesn't
     *   re-query.
     *
     * The cache deliberately namespaces the kind — a list and a view that
     * shared the same UUID would still hit distinct entries.
     */
    calculateVennDataForOperands(operands: SetOperand[]): Promise<VennData>;
    /**
     * Operand-aware sibling of `performOperation`. `operandKeys` are the
     * `OperandCacheKey()` strings produced by `calculateVennDataForOperands`,
     * so callers can stay in operand-key space end-to-end.
     */
    performOperationForOperands(operation: SetOperation, operands: SetOperand[], allOperands?: SetOperand[]): Promise<SetOperationResult>;
    /**
     * Calculate all possible intersections between the given sets
     */
    private calculateAllIntersections;
    /**
     * Calculate records that are in ALL of the specified sets but NONE of the other sets
     */
    private calculateExclusiveIntersection;
    /**
     * Build a display label for an intersection
     */
    private buildIntersectionLabel;
    /**
     * Perform a set operation on multiple lists
     */
    performOperation(operation: SetOperation, listIds: string[], allListIds?: string[]): Promise<SetOperationResult>;
    /**
     * Cached lookup keyed by operand kind+id. Lists and views share the
     * cache map but their entries can't collide thanks to the key namespace.
     */
    private cacheGet;
    /**
     * Bulk-load any operands not already cached. Lists batch through a
     * single `MJ: List Details` query (same shape as before); views resolve
     * one at a time because each is a separate parameterized RunView. Both
     * paths populate the same cache map.
     */
    private ensureOperandsLoaded;
    private loadMissingLists;
    private loadMissingViews;
    /**
     * Resolve a view to a set of record IDs in the canonical `MJ: List
     * Details.RecordID` format (single-PK → raw value; composite-PK →
     * `Field1|Value1||Field2|Value2`, matching `CompositeKey.ToConcatenatedString`).
     * This keeps view operands cache-compatible with list operands without
     * any transformation in the set-op logic.
     */
    private loadSingleView;
    /**
     * Mirror of `ListOperations.serializeRecordId` so view operands produce
     * IDs that round-trip cleanly against MJ List Details.
     */
    private serializeRecordId;
    /**
     * Pure compute step shared by the legacy and operand-aware paths.
     * Operates on raw `Set<string>` inputs so it stays agnostic to where
     * those sets came from.
     */
    private computeOperationResult;
    /**
     * Ensure list details are loaded for the given list IDs. Cache keys use
     * the `list:<id>` namespace introduced for operand support; the legacy
     * list-only callers go through here without needing to know the format.
     */
    private ensureListsLoaded;
    /**
     * Set intersection of two sets
     */
    private intersect;
    /**
     * Set difference (a - b)
     */
    private difference;
    /**
     * Union of multiple sets
     */
    private unionAll;
    /**
     * Intersection of multiple sets
     */
    private intersectAll;
    /**
     * Symmetric difference of multiple sets (items in exactly one set)
     */
    private symmetricDifferenceAll;
    /**
     * Get the color for a list by its index
     */
    getColorForIndex(index: number): string;
    /**
     * Clear the cache
     */
    clearCache(): void;
    static ɵfac: i0.ɵɵFactoryDeclaration<ListSetOperationsService, never>;
    static ɵprov: i0.ɵɵInjectableDeclaration<ListSetOperationsService>;
}
//# sourceMappingURL=list-set-operations.service.d.ts.map