Skip to content

Refactor type representation and editing #1878

Description

@PaulHax

Types currently come from track confidence pairs, customTypeStyling keys, and the typeHierarchy parent map. Editing must reconcile these sources, including preserving types when their last parent link disappears.

Approach Pro Con
Keep current representation No migration or behavior changes Scattered bookkeeping remains
Unify the client model; keep existing storage One type-editing path without a format migration Still translates between separate saved fields
Store one explicit type catalog with optional parents Type existence no longer depends on styles or relationships Requires migration and Web/Desktop import/export changes

related: #1877

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions