Filtering of Arrows and Annotations

[williamsyang-work]

Current Problem

We're implementing string/regex filtering for states in the time graph visualization. While states are properly filtered via the tags property from the backend, we've identified a gap in handling related arrows and annotations.

Current Data Structures (tsp-typescript-client / trace-server-protocol)

interface TimeGraphState {
    start: bigint;
    end: bigint;
    label?: string;
    tags?: number;    // Indicates if state is filtered
    style?: OutputElementStyle;
}

interface TimeGraphArrow {
    end: bigint;
    sourceId: number;
    start: bigint;
    targetId: number;
    style: OutputElementStyle;
}

interface Annotation {
    duration: bigint;
    entryId: number;
    time: bigint;
    style: OutputElementStyle;
}

Core Issue

Currently, there's no explicit relationship between:

• States and their related arrows
• States and their related annotations

This makes it very difficult for the frontend to efficiently determine which arrows/annotations should be filtered when their associated states are filtered.

Proposed Solutions

Solution 1: Backend-Handled Filtering (Preferred)

Approach

Extend the current filtering mechanism where the backend applies tags to arrows and annotations in addition to states.

Modified Data Structures

interface TimeGraphArrow {
    end: bigint;
    sourceId: number;
    start: bigint;
    targetId: number;
    style: OutputElementStyle;
    tags?: number;    // NEW: Indicates if arrow should be filtered
}

interface Annotation {
    duration: bigint;
    entryId: number;
    time: bigint;
    style: OutputElementStyle;
    tags?: number;    // NEW: Indicates if annotation should be filtered
}

Benefits

• Maintains current architecture where filtering logic lives in the backend
• No complex relationship mapping needed in frontend
• Better performance as filtering is pre-computed
• Consistent with current filtering approach for states
• Frontend remains simple: just check tags property

Implementation Notes

• Backend would need to extend its filtering logic to arrows and annotations
• Frontend can use the same filtering logic it uses for states
• No changes needed to existing data relationships

Solution 2: Relationship-Based Filtering (Alternative)

Approach

Add explicit relationships between states and their associated arrows/annotations.

Modified Data Structures

interface TimeGraphState {
    start: bigint;
    end: bigint;
    label?: string;
    tags?: number;
    style?: OutputElementStyle;
    relatedArrows?: number[];      // NEW: References to associated arrows
    relatedAnnotations?: number[]; // NEW: References to associated annotations
}

interface TimeGraphArrow {
    id: number;       // NEW: Unique identifier
    end: bigint;
    sourceId: number;
    start: bigint;
    targetId: number;
    style: OutputElementStyle;
}

interface Annotation {
    id: number;      // NEW: Unique identifier
    duration: bigint;
    entryId: number;
    time: bigint;
    style: OutputElementStyle;
}

Considerations

• Requires significant changes to data structure
• Frontend would need to:
  1. Maintain maps of arrows/annotations by ID
  2. For each filtered state, check its related items
  3. Apply filtering based on relationships
• Could impact performance with large datasets
• Moves some filtering logic to frontend
• More complex to maintain and debug

Recommendation

We recommend implementing Solution 1 (Backend-Handled Filtering) because:

1. Maintains clean separation of concerns
2. Consistent with existing architecture
3. Better performance characteristics
4. Simpler frontend implementation
5. Easier to maintain and debug

The backend team already handles filtering logic for states, so extending this to arrows and annotations would be a natural progression of the current architecture.

Next Steps

1. Discuss any technical constraints or considerations
2. Agree on implementation approach

Please let me know if you need any clarification or have additional considerations to discuss.