DictionaryService and DictionaryHub Pattern

Overview

A connection-scoped indexing pattern for referencing backend objects across hierarchical SignalR hub connections.

Core Components

DictionaryService: Manages connection-scoped index dictionaries

• First layer key: Hub connectionId (auto-generated by SignalR)
• Second layer key: LocalId (resource name)
• Value: References to backend objects (functions, getters/setters)

DictionaryHub: Base hub that auto-cleans index entries on disconnect

Architecture

Root-Hub
└── Child-Hub - has parent's connectionId
    └── Grandchild-Hub - has parent's connectionId

Each hub gets a unique system-generated hub-connectionId. Child hubs receive parent's connectionId to access parent data.

Key Patterns

1. Parent ConnectionId Passing: Child hubs copy parent's function references via connectionId
2. Frontend ConnectionId Chain: Components pass connectionId down the hierarchy
3. Wrapper Function Pattern: Child hubs should create wrapper functions that dynamically retrieve and invoke parent functions at runtime, rather than directly copying references. This ensures type safety through runtime checking and supports dynamic function updates from the parent.

Benefits

• Isolation: Each component has its own connection/index space
• Nesting Support: Same components can be nested without conflicts
• Auto-cleanup: Index entries cleaned on disconnect
• Data Inheritance: Access parent's backend objects via connectionId chain

Best Practices

• Apply or inherit from DictionaryHub for auto-cleanup
• Use meaningful key names (e.g., “transformer-getter”)
• Always setup dictionary functions unconditionally during initialization - put condition checks inside the functions, not around the setup. This ensures child panels can access functions even when parent objects temporarily don't meet the conditions.

Common Pitfalls

• Don't use child's connectionId to index parent's data