Summary
Web Components leverage the Shadow DOM and <slot> elements for declarative content projection. Currently, cdidx recognizes custom elements (hyphenated tag names) but does not track <slot> elements or their name attribute, nor does it index which elements are projected via slot="name" attributes. This limits navigation in component codebases: developers cannot easily find all slots offered by a component or all usage sites of a specific slot.
Where
src/CodeIndex/Indexer/Symbols/SymbolExtractor.Markup.cs:ExtractHtmlSymbols() — Custom element detection (lines 87–92) recognizes hyphenated tags but treats <slot> as a standard tag, not as a component contract declaration- No extraction of
slot= attribute values as references or named slot declarations
Suggested approach
- Recognize
<slot> as a special tag (not a custom element) and extract its name attribute as a "property" symbol (e.g., <slot name="footer"> → symbol kind="property", name="footer")
- Extract
slot="value" attributes on any element as "reference" symbols pointing to named slot definitions, enabling cross-linking
- Consider tracking unnamed default slot separately (e.g., via a synthetic symbol or special naming convention)
- Handle default slot content selection (e.g., fallback content inside
<slot>) with appropriate body range tracking
- Add tests for named slots, unnamed/default slots, multiple slots in one component, and slot projection chains (slot inside slot)
Summary
Web Components leverage the Shadow DOM and
<slot>elements for declarative content projection. Currently, cdidx recognizes custom elements (hyphenated tag names) but does not track<slot>elements or theirnameattribute, nor does it index which elements are projected viaslot="name"attributes. This limits navigation in component codebases: developers cannot easily find all slots offered by a component or all usage sites of a specific slot.Where
src/CodeIndex/Indexer/Symbols/SymbolExtractor.Markup.cs:ExtractHtmlSymbols()— Custom element detection (lines 87–92) recognizes hyphenated tags but treats<slot>as a standard tag, not as a component contract declarationslot=attribute values as references or named slot declarationsSuggested approach
<slot>as a special tag (not a custom element) and extract itsnameattribute as a "property" symbol (e.g.,<slot name="footer">→ symbol kind="property", name="footer")slot="value"attributes on any element as "reference" symbols pointing to named slot definitions, enabling cross-linking<slot>) with appropriate body range tracking