|
8 | 8 | * - Styling metadata for Figma plugin |
9 | 9 | */ |
10 | 10 |
|
11 | | -import type { PropSchema, PassthroughDoc, ComponentStyling } from "./types.js"; |
| 11 | +import type { |
| 12 | + PropSchema, |
| 13 | + PassthroughDoc, |
| 14 | + ComponentStyling, |
| 15 | + SubComponentConfig, |
| 16 | +} from "./types.js"; |
12 | 17 |
|
13 | 18 | // ============================================================================= |
14 | 19 | // Pass-through Component Documentation |
@@ -158,6 +163,66 @@ export const PASSTHROUGH_COMPONENT_DOCS: Record<string, PassthroughDoc> = { |
158 | 163 | </Combobox.Collection>`, |
159 | 164 | ], |
160 | 165 | }, |
| 166 | + |
| 167 | + // Tooltip sub-components |
| 168 | + "TooltipBase.Provider": { |
| 169 | + description: |
| 170 | + "Groups multiple tooltips so that after the first tooltip is shown, switching to another skips the open delay. Place once at your app root or layout.", |
| 171 | + props: { |
| 172 | + delay: { |
| 173 | + type: "number", |
| 174 | + description: |
| 175 | + "How long to wait (ms) before opening a tooltip once the pointer enters the trigger.", |
| 176 | + default: "600", |
| 177 | + }, |
| 178 | + closeDelay: { |
| 179 | + type: "number", |
| 180 | + description: "How long to wait (ms) before closing a tooltip.", |
| 181 | + default: "0", |
| 182 | + }, |
| 183 | + timeout: { |
| 184 | + type: "number", |
| 185 | + description: |
| 186 | + "Grace period (ms) during which a just-closed tooltip's delay is skipped when another tooltip opens.", |
| 187 | + default: "400", |
| 188 | + }, |
| 189 | + }, |
| 190 | + usageExamples: ["<TooltipProvider>\n <App />\n</TooltipProvider>"], |
| 191 | + }, |
| 192 | +}; |
| 193 | + |
| 194 | +// ============================================================================= |
| 195 | +// Sub-Component Overrides |
| 196 | +// ============================================================================= |
| 197 | + |
| 198 | +/** |
| 199 | + * Manual sub-component entries that are merged into the registry alongside |
| 200 | + * entries detected by `detectSubComponents()` in `sub-components.ts`. |
| 201 | + * |
| 202 | + * Use this when a component exposes a related API (e.g., a sibling named |
| 203 | + * export like `TooltipProvider`) that we want documented as a sub-component |
| 204 | + * (e.g., `Tooltip.Provider`) for the registry / docs, *without* changing the |
| 205 | + * component's runtime shape (no `Object.assign`, no attached property). |
| 206 | + * |
| 207 | + * Detected sub-components take precedence over overrides with the same |
| 208 | + * `name`, so a real source-level compound pattern will always win and |
| 209 | + * prevent silent masking of detector regressions. |
| 210 | + * |
| 211 | + * Keyed by the parent component name (e.g., "Tooltip"). Values have the same |
| 212 | + * shape as `detectSubComponents()` entries so they feed directly into the |
| 213 | + * existing processing loop in `index.ts`. |
| 214 | + */ |
| 215 | +export const SUB_COMPONENT_OVERRIDES: Record<string, SubComponentConfig[]> = { |
| 216 | + Tooltip: [ |
| 217 | + { |
| 218 | + name: "Provider", |
| 219 | + valueName: "TooltipProvider", |
| 220 | + propsType: null, |
| 221 | + description: "Provider sub-component (wraps TooltipBase)", |
| 222 | + isPassThrough: true, |
| 223 | + baseComponent: "TooltipBase.Provider", |
| 224 | + }, |
| 225 | + ], |
161 | 226 | }; |
162 | 227 |
|
163 | 228 | // ============================================================================= |
|
0 commit comments