IFClite TypeScript API
    Preparing search index...

    Interface ModelDiff<TRef>

    interface ModelDiff<TRef = unknown> {
        appliedKeyAliases?: Map<string, string>;
        byKey: Map<string, DiffEntry<TRef>>;
        contentMatches?: ContentMatch<TRef>[];
        counts: DiffCounts;
        entries: DiffEntry<TRef>[];
        excludedTypes: string[];
        scope: DiffScope;
        splitMerges?: SplitMergeClaim<TRef>[];
        successors?: SuccessorClaim<TRef>[];
    }

    Type Parameters

    • TRef = unknown
    Index
    appliedKeyAliases?: Map<string, string>

    The DiffOptions.keyAliases entries that actually took effect (head key → base key). Only present (possibly empty) when keyAliases was supplied; undefined otherwise.

    Echoed for the same reason as excludedTypes: an alias that was dropped as stale or colliding changes nothing about the result, so without this a caller cannot tell "the map matched" from "the map was ignored". A report or provenance record can state which claims it relied on rather than re-deriving them.

    byKey: Map<string, DiffEntry<TRef>>

    Entries indexed by DiffEntry.key for O(1) lookup (picking).

    contentMatches?: ContentMatch<TRef>[]

    Content-hash matches and ambiguous groups found among the leftover added/deleted entities (issue #1891). Only present (possibly empty) when DiffOptions.matchUnpairedByContent was true; undefined for a plain key-based diff.

    counts: DiffCounts
    entries: DiffEntry<TRef>[]

    All entries, in no particular order.

    excludedTypes: string[]

    The IFC type names actually excluded from this diff (DiffOptions.excludeTypes), normalized to upper case and deduplicated. Empty when nothing was excluded. Echoed here so a consumer (report export, provenance) can state what the comparison ignored without re-deriving it.

    scope: DiffScope

    The scope the diff was computed with.

    splitMerges?: SplitMergeClaim<TRef>[]

    Split / merge claims found among the entities still added/deleted after content matching (issue #1891). Only present (possibly empty) when DiffOptions.detectSplitMerge was true AND the run had geometry to reason with; undefined otherwise.

    Purely additive: entries, byKey and counts are exactly what they would have been with the option off. See SplitMergeClaim.

    successors?: SuccessorClaim<TRef>[]

    Successor claims — one deleted entity replaced in place by one added entity — found among what content matching and split/merge left unbound (issue #4955). Only present (possibly empty) when DiffOptions.detectSuccessors was true AND the run had geometry to reason with; undefined otherwise.

    Purely additive, like splitMerges: entries, byKey and counts are unchanged. Never an identity-map entry unattended; see SuccessorClaim.