igniteui-cli 15.0.0-rc.2 → 15.0.0

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
Files changed (60) hide show
  1. package/lib/commands/ai-config.d.ts +1 -2
  2. package/lib/commands/ai-config.js +4 -64
  3. package/lib/templates/IgniteUIForReactTemplate.d.ts +1 -0
  4. package/lib/templates/IgniteUIForReactTemplate.js +1 -0
  5. package/lib/templates/IgniteUIForWebComponentsTemplate.d.ts +1 -0
  6. package/lib/templates/IgniteUIForWebComponentsTemplate.js +1 -0
  7. package/lib/templates/jQueryTemplate.d.ts +1 -0
  8. package/lib/templates/jQueryTemplate.js +1 -0
  9. package/package.json +4 -4
  10. package/templates/jquery/js/projects/empty/index.js +1 -0
  11. package/templates/react/igr-ts/grid/basic/index.js +1 -1
  12. package/templates/react/igr-ts/projects/_base/files/__dot__claude/skills/igniteui-react-components/SKILL.md +23 -3
  13. package/templates/react/igr-ts/projects/_base/files/__dot__vscode/mcp.json +1 -1
  14. package/templates/react/igr-ts/projects/_base/files/package.json +1 -1
  15. package/templates/react/igr-ts/projects/_base/index.d.ts +1 -0
  16. package/templates/react/igr-ts/projects/_base/index.js +1 -0
  17. package/templates/react/igr-ts/projects/_base_with_home/index.d.ts +1 -0
  18. package/templates/react/igr-ts/projects/_base_with_home/index.js +1 -0
  19. package/templates/react/igr-ts/projects/base/index.d.ts +1 -0
  20. package/templates/react/igr-ts/projects/base/index.js +1 -0
  21. package/templates/react/igr-ts/projects/empty/index.d.ts +1 -0
  22. package/templates/react/igr-ts/projects/empty/index.js +1 -0
  23. package/templates/react/igr-ts/projects/top-nav/index.d.ts +1 -0
  24. package/templates/react/igr-ts/projects/top-nav/index.js +1 -0
  25. package/templates/webcomponents/igc-ts/card/default/files/src/app/__path__/__filePrefix__.ts +7 -5
  26. package/templates/webcomponents/igc-ts/dock-manager/default/files/src/app/__path__/__filePrefix__.ts +1 -1
  27. package/templates/webcomponents/igc-ts/grid/default/files/src/app/__path__/__filePrefix__.ts +1 -1
  28. package/templates/webcomponents/igc-ts/grid/grid-editing/files/src/app/__path__/__filePrefix__.ts +1 -1
  29. package/templates/webcomponents/igc-ts/projects/_base/files/__dot__claude/skills/README.md +3 -0
  30. package/templates/webcomponents/igc-ts/projects/_base/files/__dot__claude/skills/igniteui-wc-choose-components/SKILL.md +27 -0
  31. package/templates/webcomponents/igc-ts/projects/_base/files/__dot__claude/skills/igniteui-wc-generate-from-image-design/SKILL.md +228 -0
  32. package/templates/webcomponents/igc-ts/projects/_base/files/__dot__claude/skills/igniteui-wc-generate-from-image-design/references/component-mapping.md +130 -0
  33. package/templates/webcomponents/igc-ts/projects/_base/files/__dot__claude/skills/igniteui-wc-generate-from-image-design/references/gotchas.md +147 -0
  34. package/templates/webcomponents/igc-ts/projects/_base/files/__dot__claude/skills/igniteui-wc-integrate-with-framework/SKILL.md +22 -1
  35. package/templates/webcomponents/igc-ts/projects/_base/files/__dot__claude/skills/igniteui-wc-integrate-with-framework/references/angular.md +2 -0
  36. package/templates/webcomponents/igc-ts/projects/_base/files/__dot__claude/skills/igniteui-wc-integrate-with-framework/references/react.md +2 -0
  37. package/templates/webcomponents/igc-ts/projects/_base/files/__dot__claude/skills/igniteui-wc-integrate-with-framework/references/vanilla-js.md +2 -0
  38. package/templates/webcomponents/igc-ts/projects/_base/files/__dot__claude/skills/igniteui-wc-integrate-with-framework/references/vue.md +2 -0
  39. package/templates/webcomponents/igc-ts/projects/_base/files/__dot__vscode/mcp.json +1 -1
  40. package/templates/webcomponents/igc-ts/projects/_base/files/eslint.config.js +5 -3
  41. package/templates/webcomponents/igc-ts/projects/_base/files/index.html +1 -1
  42. package/templates/webcomponents/igc-ts/projects/_base/files/package.json +7 -22
  43. package/templates/webcomponents/igc-ts/projects/_base/files/src/app/app-routing.ts +1 -1
  44. package/templates/webcomponents/igc-ts/projects/_base/files/tsconfig.json +22 -29
  45. package/templates/webcomponents/igc-ts/projects/_base/files/vite.config.ts +3 -4
  46. package/templates/webcomponents/igc-ts/projects/_base/index.d.ts +1 -0
  47. package/templates/webcomponents/igc-ts/projects/_base/index.js +1 -0
  48. package/templates/webcomponents/igc-ts/projects/_base_with_home/files/index.html +1 -1
  49. package/templates/webcomponents/igc-ts/projects/_base_with_home/files/package.json +7 -22
  50. package/templates/webcomponents/igc-ts/projects/_base_with_home/files/src/app/app-routing.ts +1 -1
  51. package/templates/webcomponents/igc-ts/projects/_base_with_home/index.d.ts +1 -0
  52. package/templates/webcomponents/igc-ts/projects/_base_with_home/index.js +1 -0
  53. package/templates/webcomponents/igc-ts/projects/base/index.d.ts +1 -0
  54. package/templates/webcomponents/igc-ts/projects/base/index.js +1 -0
  55. package/templates/webcomponents/igc-ts/projects/empty/index.d.ts +1 -0
  56. package/templates/webcomponents/igc-ts/projects/empty/index.js +1 -0
  57. package/templates/webcomponents/igc-ts/projects/side-nav/files/src/app/app.ts +11 -8
  58. package/templates/webcomponents/igc-ts/projects/side-nav/index.d.ts +1 -0
  59. package/templates/webcomponents/igc-ts/projects/side-nav/index.js +1 -0
  60. package/templates/webcomponents/igc-ts/projects/_base/files/tsconfig.test.json +0 -14
@@ -0,0 +1,228 @@
1
+ ---
2
+ name: igniteui-wc-generate-from-image-design
3
+ description: Implement application views from design images using Ignite UI Web Components. Uses MCP servers (igniteui-cli, igniteui-theming) to discover components, generate themes, and follow best practices. Triggers when the user provides a design image (screenshot, mockup, wireframe) and wants it built as a working view with Ignite UI Web Components. Also triggers when the user asks to "implement this design", "build this UI", "convert this mockup", or "create a page from this image" in an Ignite UI Web Components project.
4
+ user-invocable: true
5
+ ---
6
+
7
+ # Implementing Ignite UI Web Components Views from Design Images
8
+
9
+ ## MANDATORY AGENT PROTOCOL
10
+
11
+ Before writing any implementation code, you must complete these steps in order:
12
+
13
+ 1. Analyze the image and identify all visible regions and UI patterns.
14
+ 2. Read [references/component-mapping.md](references/component-mapping.md) and [references/gotchas.md](references/gotchas.md).
15
+ 3. This skill is Web Components-first. Check package layout or licensing only when package choice, component registration, or theming depend on it.
16
+ 4. To apply a theme, use the theming workflow from this skill and the dedicated `igniteui-wc-customize-component-theme` skill; use the `igniteui-theming` MCP tools instead of styling from memory.
17
+ 5. Call `get_doc` for every chosen component family before using it.
18
+ 6. Only then start coding.
19
+
20
+ ## Workflow
21
+
22
+ 1. **Analyze the design image** - Read the image, identify every UI section, component, layout structure.
23
+ 2. **Confirm package layout if needed** - Web Components packages are split by component family; check package layout or licensing only when package choice, component registration, or theming depend on it.
24
+ 3. **Discover components** - Call `list_components` with targeted filters to find matching components for each UI pattern.
25
+ 4. **Look up component docs** - Call `get_doc` for every chosen component family before coding.
26
+ 5. **Generate theme** - (a) To generate a theme, first extract colors and create a color palette using `create_palette` or `create_custom_palette` depending on the scenario. Then extract elevations and call `create_elevations`. Then extract typography and call `create_typography`. Then call `create_theme` when Sass is configured, or import the closest pre-built theme CSS. (b) After a theme exists, prefer using design tokens or scoped semantic CSS variables over raw literals. (c) For every Ignite UI component family that exposes design tokens, call `get_component_design_tokens`, map extracted image tokens to token roles, then call `create_component_theme` with the tokens differing from the global theme for the specific component.
27
+ 6. **Implement** - Build the screenshot-first layout, data, and view components.
28
+ 7. **Refine** - Use the `set_size`, `set_spacing`, `set_roundness` tools to refine the view's visual fidelity against the image, then iterate on implementation and theming until the view matches the design closely.
29
+ 8. **Validate** - Build, test, run, compare against the image, and fix differences.
30
+
31
+ ## Step 1: Analyze the Design Image
32
+
33
+ Read the input image carefully. For each visual section, identify:
34
+
35
+ - **Layout structure**: grid rows/columns, sidebar, navbar, content area proportions, and estimated fixed widths or percentages for major regions.
36
+ > Note: Do not guess the exact CSS properties at this stage; just identify the high-level structure and relative proportions. Do not try to fit the view into exact breakpoints or pixel values. Try to generate a flexible layout that preserves the observed proportions and can adapt to different screen sizes. You will refine the exact CSS rules in Step 8 after building a first version of the view.
37
+ - **Component type**: chart, list, card, grid, form, navigation, etc.
38
+ - **Color palette**: primary, secondary, surface/background, accent, text colors.
39
+ - **Typography**: font sizes, weights, letter-spacing patterns.
40
+ - **Surface styling**: borders, border-radius, shadows, elevation, divider treatments.
41
+ - **Data patterns**: what mock data is needed (time series, lists, KPIs, tabular, scheduling).
42
+ - **Spacing system**: translate observed padding and gaps into a small reusable scale derived from the design.
43
+
44
+ Before writing code, create a decomposition table with one row per visible region containing:
45
+
46
+ | Region | Visual role | Candidate component | Custom CSS required | Data type |
47
+ |---|---|---|---|---|
48
+ | Example: sidebar item list | repeated rows with icon + label | `IgcListComponent` + `IgcListItemComponent` | yes - item height, icon size | domain-appropriate mock data |
49
+ | Example: top bar | brand + tabs + search | `IgcNavbarComponent` | yes - multi-zone slot layout | n/a |
50
+ | Example: side panel | always-visible navigation | `IgcNavDrawerComponent` | yes - width, item styling | n/a |
51
+
52
+ Start every region with the most appropriate Ignite UI component from [references/component-mapping.md](references/component-mapping.md). Only fall back to plain semantic HTML when the component DOM structure is fundamentally incompatible with the design after CSS overrides, tokens, slots, and documented `::part(...)` selectors are considered. Document the reason for any plain-HTML fallback in a code comment.
53
+
54
+ Before writing code, produce a compact implementation brief that captures:
55
+
56
+ - chosen components per region
57
+ - fallback HTML regions
58
+ - theme strategy
59
+ - package needs
60
+ - component registration needs
61
+ - major assumptions
62
+
63
+ After the table, translate the image into CSS Grid rows and columns first. Preserve desktop proportions before adding responsive behavior, then define explicit breakpoint stacking rules for smaller screens.
64
+
65
+ ## Step 2-3: Use MCP Tools for Discovery
66
+
67
+ This skill is Web Components-first. Check package layout or licensing only when package choice, component registration, or theming depend on it.
68
+
69
+ - If the project is unlicensed or uses trial package layout, do not mark documented trial packages as blocked or licensed-only during implementation.
70
+ - If the result indicates a licensed package layout, follow the licensed import paths shown in the component reference when needed.
71
+
72
+ Then call `list_components` with `framework: "webcomponents"` and relevant filters to find components matching each UI pattern. Common filters:
73
+
74
+ - `chart`, `sparkline` - for data visualization
75
+ - `list view`, `card`, `avatar`, `badge` - for data display
76
+ - `nav`, `navbar`, `drawer`, `dock manager` - for navigation and shell layouts
77
+ - `progress` - for metrics
78
+ - `grid lite`, `data grid`, `tree grid` - for tabular data
79
+ - `calendar`, `date picker`, `combo`, `select`, `input` - for forms and scheduling
80
+
81
+ Use narrow search terms to reduce noisy MCP results. Search for the specific UI pattern you need, such as `list view` instead of `list`.
82
+
83
+ For component-to-Ignite-UI mapping, see [references/component-mapping.md](references/component-mapping.md).
84
+
85
+ ## Step 4: Look Up Component API
86
+
87
+ For every chosen component category, call `get_doc` with the doc name from `list_components` results (e.g., `name: "card"`, `framework: "webcomponents"`). Use the doc `name` field from the MCP results, not the result title shown in the list. This is mandatory before coding and gives exact usage patterns, slots, events, registration, and API structure.
88
+
89
+ Call `search_docs` for feature-based questions (e.g., "how to configure [component] for [specific behavior or styling need]").
90
+
91
+ ## Step 5: Generate Theme with MCP
92
+
93
+ Use this skill for the image-to-view theming workflow only. The dedicated [`igniteui-wc-customize-component-theme`](../igniteui-wc-customize-component-theme/SKILL.md) skill remains the source of truth for palette-token behavior, global theme rules, and broader theming-system guidance.
94
+
95
+ ### 5a - Existing app guard (always run first)
96
+
97
+ Before generating any theme code, inspect the project's entry point and main stylesheet(s) (commonly `main.ts`, `main.js`, `index.ts`, `app.ts`, `styles.css`, or the app's main theme stylesheet). Look for:
98
+
99
+ - an imported pre-built theme CSS file such as `igniteui-webcomponents/themes/light/material.css`
100
+ - existing palette tokens or semantic CSS variables already exposed by the app
101
+ - existing app-level typography or elevation variables already exposed by the app
102
+
103
+ - **Existing theme found** -> the global theme is already set. Do **not** call `create_palette` unless the user explicitly wants a global theme change. Instead:
104
+ 1. Inspect the existing theme import, palette definition, and any exposed semantic CSS variables.
105
+ 2. Reuse the current design system, variant, and palette tokens wherever they already match the design image.
106
+ 3. Skip to **5c** and apply only minimal scoped overrides for the new view's components.
107
+ - **No theme found / blank theme setup** -> proceed with **5b** to generate a fresh CSS-based theme baseline.
108
+
109
+ ### 5b - Global theme generation (new projects only)
110
+
111
+ Follow this order - MCP guidance first, image extraction second:
112
+
113
+ 1. **Read MCP guidance first** - call `theming://guidance/colors/rules` (or `get_theming_guidance`) before looking at the image. This tells you the available theme inputs and any luminance or variant constraints.
114
+ 2. **Resolve the design system** - infer it from the existing workspace, explicit user request, or the closest visual match in the design. Do not assume one if a stronger signal exists.
115
+ 3. **Extract from the image** - now that you know the available slots, extract values only for the inputs you actually need.
116
+ 4. **Call `create_palette` or `create_custom_palette`** with the extracted seed values:
117
+
118
+ ```
119
+ create_palette({
120
+ primary: "<color extracted from image for primary slot>",
121
+ secondary: "<color extracted from image for secondary slot>",
122
+ surface: "<color extracted from image for surface/background slot>",
123
+ variant: "<resolved theme variant>",
124
+ platform: "webcomponents"
125
+ })
126
+ ```
127
+
128
+ Import the closest built-in theme CSS for the resolved design system and variant, then use `get_color` to translate the generated palette into CSS custom properties, semantic app tokens, and component token values. Apply typography decisions with standard CSS `font-family`, `font-size`, and `font-weight` rules, and apply elevations with CSS box-shadow values or semantic shadow variables.
129
+
130
+ Read and act on any luminance warnings returned. If the design needs multiple surface depths that a single generated surface color does not cover, use `create_custom_palette` or define semantic CSS variables for the additional depths in the main stylesheet.
131
+
132
+ Use `create_palette` for straightforward designs with a small, coherent color system. Use `create_custom_palette` when the design has multiple distinct surface depths, several accent families, or when the generated palette cannot reliably match the screenshot.
133
+
134
+ ### 5c - Per-component token discovery and mapping (always run)
135
+
136
+ > **Scope:** this step applies to every Ignite UI Web Components family that exposes design tokens. Core components - cards, inputs, select, combo, navbar, nav drawer, list, tabs, date pickers, chips, etc. - are the primary targets. For packages or components that do not expose a practical token surface in the current project, fall back to documented properties, `::part(...)` selectors, or wrapper styles instead of inventing unsupported tokens.
137
+
138
+ For **every** chosen Ignite UI component family in Steps 3-4, follow this MCP-first loop - query MCP before touching the image:
139
+
140
+ 1. **Discover (MCP first)** - call `get_component_design_tokens(component)` before looking at the image for that component. Read the full token list with names, types, and descriptions. Identify which tokens correspond to visible surfaces, text, borders, icons, and interaction states.
141
+ 2. **Extract (image second)** - now that you know the exact token names, go to the image region for that component and read the exact token value for each relevant token slot. Do not guess; zoom into the component region.
142
+ 3. **Generate** - call `create_component_theme(component, platform, licensed, tokens)` passing only the tokens whose resolved value differs from the global theme. This produces the minimal scoped theme override set for the component.
143
+
144
+ **Example - theming a grid:**
145
+ - `get_component_design_tokens("grid")` returns `header-background`, `content-background`, `row-hover-background` among many others.
146
+ - Look at the grid region in the image -> extract the color intent for header, row background, and hover state.
147
+ - Resolve each value to a palette token or local semantic CSS variable.
148
+ - Call `create_component_theme("grid", ...)` with only `{ "header-background": "<resolved token>", "content-background": "<resolved token>", "row-hover-background": "<resolved token>" }`.
149
+
150
+ Apply the generated theme blocks to the component selector or a scoped wrapper exactly as shown in the `create_component_theme` output.
151
+
152
+ Do not run `create_component_theme` for regions built with custom HTML/CSS only.
153
+
154
+ ### 5d - Theming sequence summary
155
+
156
+ Apply in this exact order:
157
+
158
+ 1. Inspect the entry point and main stylesheet(s) -> existing theme or blank?
159
+ 2. Create or update a theme baseline: pre-built theme import plus palette-backed CSS variables and token overrides (Step 5b)
160
+ 3. For each Ignite UI component: `get_component_design_tokens` -> map image design tokens -> resolve values to design tokens or semantic CSS variables -> `create_component_theme` (Step 5c)
161
+ 4. Use `get_color` after palette generation whenever a palette token can represent the final color intent
162
+
163
+ Use standard CSS `font-family` lists in stylesheets or CSS variables for typography. Do not emit Sass typography mixins for Ignite UI Web Components apps.
164
+
165
+ ## Step 6: Install Required Packages
166
+
167
+ General UI components ship with `igniteui-webcomponents`. Lightweight tabular data can use `igniteui-grid-lite`. Advanced grids, dock manager, and charts require additional packages and may vary by trial versus licensed package layout. Resolve the selected component families against the current workspace and [references/component-mapping.md](references/component-mapping.md).
168
+
169
+ After selecting packages, register only the custom elements you actually use with `defineComponents(...)` in the appropriate entry point or setup module, unless the host framework integration already handles registration differently. Use [`igniteui-wc-integrate-with-framework`](../igniteui-wc-integrate-with-framework/SKILL.md) when framework-specific setup details matter.
170
+
171
+ If required packages are missing, identify the exact packages and versions required first, then ask for approval before installing packages or changing dependency manifests.
172
+
173
+ ## Step 7: Implement
174
+
175
+ ### Structure
176
+
177
+ - **Layout**: use Ignite UI layout and data-display components as the starting point for standard regions, then apply CSS Grid/Flexbox and component overrides to match the screenshot. Only substitute plain semantic HTML when an Ignite UI component remains structurally incompatible after a genuine attempt.
178
+ - **Data**: use typed mock data that matches the design's density and domain; add models/services only when they help the implementation.
179
+ - **View**: keep layout, spacing, typography, and surface styling in CSS rather than inline attributes.
180
+ - **Theming**: apply the resolved design system and theme variant from Step 5, and keep color usage aligned with palette tokens or local semantic CSS variables.
181
+
182
+ ### Implementation Checks
183
+
184
+ - Follow repo conventions from `.github/copilot-instructions.md` and `.github/CODING_GUIDELINES.md`.
185
+ - Use [references/component-mapping.md](references/component-mapping.md) for component-choice and semantic-fallback rules.
186
+ - Use [references/gotchas.md](references/gotchas.md) for components, theming, registration, and API edge cases instead of re-encoding those rules inline.
187
+ - Favor Ignite UI components over custom HTML when both approaches can reach similar visual fidelity.
188
+ - Register only the custom elements you actually use, and place registration in the project's existing entry-point pattern.
189
+ - Use slots, parts, and documented component APIs before reaching for shadow-DOM workarounds.
190
+ - Preserve spacing, hierarchy, and data density before adding extra interactivity.
191
+ - Avoid generic placeholders when the image shows domain-specific content.
192
+ - Document brief assumptions when the image is ambiguous instead of silently guessing.
193
+
194
+ ## Step 8: Refine
195
+
196
+ After the first implementation pass, use the `set_size`, `set_spacing`, and `set_roundness` tools to adjust the view's visual properties and close the gap with the image. Focus on the most visually distinctive elements first (e.g., panel proportions, chart shape, button prominence) before tuning smaller details (e.g., row heights, spacing between regions).
197
+
198
+ ## Step 9: Validate
199
+
200
+ Use this validation loop explicitly:
201
+
202
+ 1. Build
203
+ 2. Test
204
+ 3. Run the app
205
+ 4. Visually compare against the image
206
+ 5. Adjust and repeat
207
+
208
+ In terminal-only environments, the user performs the visual comparison and provides feedback on any mismatches. Only perform the visual check directly when the environment has browser and screenshot capabilities available to the agent.
209
+
210
+ Use this checklist during the first visual comparison:
211
+
212
+ - panel proportions
213
+ - control density
214
+ - chart shape
215
+ - legend placement
216
+ - button prominence
217
+ - row heights
218
+ - spacing between regions
219
+
220
+ Fix TypeScript, registration, markup, or build errors immediately during the build/test steps. Use the build output, component docs, [references/gotchas.md](references/gotchas.md), and the user's visual feedback to close the remaining gaps. Typical adjustments include:
221
+
222
+ - revisiting chart data density, smoothing, or marker visibility
223
+ - adjusting layout ratios, region spacing, or row heights
224
+ - correcting navigation mode, panel chrome, package choice, or component choice
225
+ - tuning theme tokens, component overrides, and dark-surface hierarchy
226
+ - re-examining the original design for overlooked sections or missing registration/imports
227
+
228
+ After the build succeeds with zero errors, refine layout proportions, color values, missing sections, and typography until the view matches closely.
@@ -0,0 +1,130 @@
1
+ # Ignite UI Web Components Component Mapping Reference
2
+
3
+ ## Table of Contents
4
+ - [Dashboard & Layout Components](#dashboard--layout-components)
5
+ - [Chart Components](#chart-components)
6
+ - [Data Display Components](#data-display-components)
7
+ - [Form & Input Components](#form--input-components)
8
+ - [Calendar & Scheduling Components](#calendar--scheduling-components)
9
+ - [Package Requirements](#package-requirements)
10
+ - [Import Patterns](#import-patterns)
11
+
12
+ ## Dashboard & Layout Components
13
+
14
+ | UI Pattern | Ignite UI Component | Key Properties |
15
+ |---|---|---|
16
+ | Top navigation bar | `IgcNavbarComponent` | `slot="start"`, default slot, `slot="end"` |
17
+ | Side navigation | `IgcNavDrawerComponent` | `open`, `position`, default slot, `slot="mini"` |
18
+ | Content cards/panels | `IgcCardComponent` | `<igc-card-header>`, `<igc-card-content>`, `<igc-card-actions>` |
19
+ | Tabbed content | `IgcTabsComponent` | `<igc-tab>` children, `alignment`, `activation` |
20
+ | Accordion sections | `IgcAccordionComponent` | `IgcExpansionPanelComponent` children |
21
+ | Split layouts | `IgcSplitterComponent` | pane-based layout, nested split regions |
22
+ | Tile dashboard | `IgcTileManagerComponent` | drag/resize tiles |
23
+ | IDE-style dock layout | `IgcDockManagerComponent` | floating/docking panels (Commercial) |
24
+
25
+ Decision rule:
26
+
27
+ - Use `IgcNavbarComponent` for a top horizontal bar when its slot structure and behavior match the screenshot. Use slotted content and CSS flex overrides to achieve multi-zone layouts inside it. Use a plain `<header>` when that is a closer structural fit.
28
+ - Use `IgcNavDrawerComponent` for a sidebar or side-navigation panel when drawer structure and behavior match the screenshot. Configure `open`, `position`, and mini content according to whether the design shows fixed, collapsible, or icon-only navigation. Use a plain `<aside>` when a static custom sidebar matches the screenshot better.
29
+ - Use `IgcTabsComponent` for a horizontal tab strip when the screenshot clearly shows tabbed state switching.
30
+ - Use `IgcDockManagerComponent` only when the screenshot truly shows docked, floating, or IDE-like panels. Do not substitute it for a simple dashboard grid.
31
+
32
+ Component decision matrix (by visual pattern, domain-neutral):
33
+
34
+ | Visual Pattern | Recommended Component | Notes |
35
+ |---|---|---|
36
+ | Repeated rows with icon/text/action | `IgcListComponent` + `IgcListItemComponent` | Use when the row anatomy and interaction model match; use `slot="title"`, `slot="subtitle"`, `slot="start"`, `slot="end"`. Use native `<ul>/<li>` or custom containers when that is a closer visual fit |
37
+ | Spreadsheet-like editable or sortable table | `IgcGridComponent` | Use `igniteui-grid-lite` for lightweight tables and advanced grid packages when the screenshot needs built-in editing, paging, filtering, grouping, summaries, hierarchy, or pivoting |
38
+ | Hierarchical or tree-structured table | `IgcTreeGridComponent` or `IgcHierarchicalGridComponent` | Use when rows have parent-child or master-detail relationships |
39
+ | Content blocks / summary cards | `IgcCardComponent` | Use when card chrome helps match the panel shape and structure. Use header/content/actions subcomponents with slotted content. Use plain `<div>` containers for flat or highly custom tiles |
40
+ | Any text input field | `IgcInputComponent` | Use when the input anatomy matches the screenshot, including search fields and inline editors. Apply CSS and tokens to match the screenshot's border/radius style |
41
+ | Dropdown or select | `IgcSelectComponent` | Use when the screenshot clearly shows select/dropdown behavior |
42
+ | Form fields with labels and inputs | `IgcInputComponent`, `IgcSelectComponent`, `IgcComboComponent`, `IgcDatePickerComponent` | Cover text, select, combo, and date inputs |
43
+ | Multi-step form / wizard | `IgcStepperComponent` | Use when a sequence of steps is visually present |
44
+ | Filter chips / tag inputs | `IgcChipComponent` | Use when chip anatomy matches status badges, filter tags, or removable labels in the screenshot |
45
+ | Calendar or date picker as a primary view element | `IgcCalendarComponent`, `IgcDatePickerComponent`, `IgcDateRangePickerComponent` | Use when scheduling or date selection is the core UI |
46
+ | Top icon/action bar | `IgcNavbarComponent` with slotted icon buttons | Use when a navbar structure matches the screenshot; use plain icon buttons or custom containers when that is a closer fit |
47
+
48
+ ## Chart Components
49
+
50
+ | UI Pattern | Ignite UI Component | Key Properties |
51
+ |---|---|---|
52
+ | Area chart | `IgcCategoryChartComponent` | `chartType`, `markerTypes`, `brushes`, `outlines` |
53
+ | Line chart | `IgcCategoryChartComponent` | `chartType`, `markerTypes`, `brushes` |
54
+ | Column/bar chart | `IgcCategoryChartComponent` or `IgcDataChartComponent` | `chartType`, `markerTypes`, series configuration |
55
+ | Sparkline (mini chart) | `IgcSparklineComponent` | `displayType`, `valueMemberPath` |
56
+ | Pie/donut chart | `IgcPieChartComponent` / `IgcDoughnutChartComponent` | `valueMemberPath`, `labelMemberPath` |
57
+ | Financial chart | `IgcFinancialChartComponent` | OHLC/candlestick data |
58
+ | Complex multi-series | `IgcDataChartComponent` | multiple series plus axes |
59
+
60
+ Decision rule:
61
+
62
+ - Financial or OHLC screenshot: prefer `IgcFinancialChartComponent`.
63
+ - Simple or moderate trend panel: prefer `IgcCategoryChartComponent`; move to `IgcDataChartComponent` when you need lower-level per-series control.
64
+ - Highly custom sparkline or microchart: use `IgcSparklineComponent` or a custom fallback if the built-in anatomy is not a close visual match.
65
+
66
+ ## Data Display Components
67
+
68
+ | UI Pattern | Ignite UI Component | Key Properties |
69
+ |---|---|---|
70
+ | Item list | `IgcListComponent` + `IgcListItemComponent` | `slot="title"`, `slot="subtitle"`, `slot="start"`, `slot="end"` |
71
+ | User avatar | `IgcAvatarComponent` | `initials`, `shape`, `src` |
72
+ | Status badge | `IgcBadgeComponent` | `value`, styling |
73
+ | Icons | `IgcIconComponent` | `name`, `collection`, styling |
74
+ | Progress bar | `IgcLinearProgressComponent` | `value`, `max` |
75
+ | Circular progress | `IgcCircularProgressComponent` | `value`, `max` |
76
+ | Flat data grid | `IgcGridComponent` | Grid Lite or full Data Grid depending features |
77
+ | Hierarchical/tree data grid | `IgcTreeGridComponent` / `IgcHierarchicalGridComponent` | hierarchical data support |
78
+ | Filter/tag chips | `IgcChipComponent` | `removable`, `selectable` |
79
+
80
+ Decision rule:
81
+
82
+ - Use `IgcListComponent` for repeated-row content lists when its row structure and interaction model match the screenshot. The component adds accessible keyboard navigation, item structure, and theming when those benefits fit the design. Use native `<ul>/<li>` or custom containers when they are a closer visual fit.
83
+ - Choose `IgcGridComponent` only when the image is truly tabular (flat rows and columns, spreadsheet-style). Resolve whether the lightweight or advanced grid package is the right fit from the required behavior.
84
+ - Choose `IgcTreeGridComponent` or `IgcHierarchicalGridComponent` when rows have parent-child or nested structure.
85
+ - Use `IgcChipComponent` when chip anatomy matches the screenshot's status badges, tags, or label pills. Use custom badge or pill markup when a simpler or more exact visual match is needed.
86
+
87
+ ## Form & Input Components
88
+
89
+ | UI Pattern | Ignite UI Component | Key Properties |
90
+ |---|---|---|
91
+ | Text input | `IgcInputComponent` | `type`, `value`, prefix/suffix/helper slots |
92
+ | Dropdown select | `IgcSelectComponent` | `<igc-select-item>` children, prefix/suffix slots |
93
+ | Searchable multi-select | `IgcComboComponent` | data binding, display/value keys, selection mode |
94
+ | Date picker | `IgcDatePickerComponent` | `value`, `min`, `max` |
95
+ | Time or date-time entry | `IgcDateTimeInputComponent` | typed editing for date/time fields |
96
+ | Toggle switch | `IgcSwitchComponent` | checked state, change events |
97
+ | Checkbox | `IgcCheckboxComponent` | checked state, validation |
98
+ | Radio button group | `IgcRadioGroupComponent` + `IgcRadioComponent` | grouped selection |
99
+ | Slider | `IgcSliderComponent` | `min`, `max`, labels/ticks |
100
+ | Multi-step wizard | `IgcStepperComponent` + `IgcStepComponent` | orientation, linear step flow |
101
+ | Chip filter bar | `IgcChipComponent` or `IgcButtonGroupComponent` | choose based on chip versus segmented-control anatomy |
102
+
103
+ ## Calendar & Scheduling Components
104
+
105
+ | UI Pattern | Ignite UI Component | Key Properties |
106
+ |---|---|---|
107
+ | Calendar view | `IgcCalendarComponent` | `value`, selection mode |
108
+ | Date range picker | `IgcDateRangePickerComponent` | `value`, range selection |
109
+ | Month/year picker | `IgcCalendarComponent` | month/year modes when the calendar UI is primary |
110
+
111
+ ## Package Requirements
112
+
113
+ The main `igniteui-webcomponents` package contains general UI components (list, avatar, navbar, drawer, card, badge, progress, icon, inputs, scheduling, layout, etc.).
114
+
115
+ Additional packages may be required beyond the main package:
116
+
117
+ | Capability | Additional packages |
118
+ |---|---|
119
+ | Lightweight tabular data | `igniteui-grid-lite` |
120
+ | Advanced grids | `igniteui-webcomponents-grids` (trial) or `@infragistics/igniteui-webcomponents-grids` (licensed) |
121
+ | Charts / sparklines | `igniteui-webcomponents-core` + `igniteui-webcomponents-charts` (trial) or licensed equivalents |
122
+ | Dock manager | `igniteui-dockmanager` (trial) or `@infragistics/igniteui-dockmanager` (licensed) |
123
+
124
+ Install only the packages required by the components you actually selected. Resolve the exact package layout from the current workspace before installing or importing.
125
+
126
+ ## Import Patterns
127
+
128
+ Treat this file as a component selection reference, not as authoritative import guidance for a specific repo. Confirm exact imports and registration from `detect_platform`, the current workspace, framework setup, and `get_doc` results.
129
+
130
+ For direct Web Components usage, import the component classes from the selected package and register only the needed elements with `defineComponents(...)`. If the host app uses React, Angular, Vue, or another wrapper pattern around Web Components, follow [`igniteui-wc-integrate-with-framework`](../../igniteui-wc-integrate-with-framework/SKILL.md) for the final setup details.
@@ -0,0 +1,147 @@
1
+ # Ignite UI Web Components Gotchas & Pitfalls
2
+
3
+ ## Table of Contents
4
+ - [Component Registration](#component-registration)
5
+ - [Chart Properties](#chart-properties)
6
+ - [Component Properties](#component-properties)
7
+ - [Theming Pitfalls](#theming-pitfalls)
8
+ - [Dark Theme Specifics](#dark-theme-specifics)
9
+
10
+ ## Component Registration
11
+
12
+ ### `defineComponents(...)` is required for direct Web Components usage
13
+ Register only the custom elements you actually use, and register them from the correct package:
14
+ ```ts
15
+ import {
16
+ defineComponents,
17
+ IgcCardComponent,
18
+ IgcNavbarComponent,
19
+ } from 'igniteui-webcomponents';
20
+
21
+ defineComponents(IgcNavbarComponent, IgcCardComponent);
22
+ ```
23
+
24
+ If the current app uses React, Angular, Vue, or another integration layer around Web Components, follow [`igniteui-wc-integrate-with-framework`](../../igniteui-wc-integrate-with-framework/SKILL.md) instead of duplicating registration patterns blindly.
25
+
26
+ ### Package family matters
27
+ Do not assume everything comes from `igniteui-webcomponents`. Advanced grids, charts, and dock manager live in separate packages and may have trial versus licensed package names. Resolve the package first, then register components from that package.
28
+
29
+ ## Chart Properties
30
+
31
+ ### Markers shown by default
32
+ Category charts can show markers by default. If the screenshot does not show markers, set `markerTypes` to the matching no-marker option documented for the component. Confirm the exact value shape from `get_doc`.
33
+
34
+ ### `plotAreaBackground` does NOT exist on `igc-category-chart`
35
+ Use CSS to style the chart container background instead.
36
+
37
+ ### `areaFillOpacity` exists on `IgcCategoryChartComponent`
38
+ It does NOT exist on `IgcSparklineComponent`.
39
+
40
+ ### `includedProperties` must be a real array
41
+ Assign it as an array through JavaScript or TypeScript, not as a serialized string:
42
+ ```ts
43
+ const chart = document.querySelector('igc-category-chart');
44
+ chart.includedProperties = ['fieldOne', 'fieldTwo', 'fieldThree'];
45
+ ```
46
+ Replace `'fieldOne'`, `'fieldTwo'`, etc. with the actual data property names from your mock data.
47
+
48
+ ### Chart callback properties must be assigned as functions
49
+ Function-valued chart APIs should be assigned on the element instance, not passed as string attributes:
50
+ ```ts
51
+ const chart = document.querySelector('igc-category-chart');
52
+ chart.xAxisFormatLabel = labelFormatter;
53
+ ```
54
+
55
+ ### Smooth area charts
56
+ For smooth-looking area charts where the data should appear continuous rather than spiky:
57
+ - Increase data density until the line or area reads as continuous at the rendered size.
58
+ - Apply smoothing only when the source shape in the design looks smoothed rather than point-to-point.
59
+ - Hide markers unless the screenshot clearly shows visible data points.
60
+ - Tune fill opacity and label density to match the screenshot instead of relying on a fixed default.
61
+
62
+ ### Charts inside CSS Grid can collapse
63
+ In a flexible CSS Grid track, set the grid cell and chart sizing values explicitly so the chart does not collapse:
64
+ ```css
65
+ .chart-panel {
66
+ min-height: <resolved-grid-cell-min-height>;
67
+ }
68
+
69
+ igc-category-chart {
70
+ display: <resolved-chart-display>;
71
+ height: <resolved-chart-height>;
72
+ }
73
+ ```
74
+
75
+ ## Component Properties
76
+
77
+ ### Avatar shape is controlled by `shape`
78
+ Use the supported `shape` API (`circle`, `rounded`, `square`, etc. as documented for the component).
79
+
80
+ ### List item title and subtitle are slots
81
+ Use the Web Components slot anatomy:
82
+ ```html
83
+ <igc-list-item>
84
+ <span slot="start"><resolved-leading-content></span>
85
+ <span slot="title"><resolved-title></span>
86
+ <span slot="subtitle"><resolved-subtitle></span>
87
+ <span slot="end"><resolved-trailing-content></span>
88
+ </igc-list-item>
89
+ ```
90
+
91
+ ### Avatar background color via CSS
92
+ ```html
93
+ <igc-avatar style="--ig-avatar-background: <resolved-avatar-background-token>;"></igc-avatar>
94
+ ```
95
+
96
+ ### Nav drawer width
97
+ The drawer sizing hooks in the current implementation are `--menu-full-width` and `--menu-mini-width`:
98
+ ```css
99
+ igc-nav-drawer {
100
+ --menu-full-width: <extracted-sidebar-width>;
101
+ --menu-mini-width: <extracted-mini-drawer-width>;
102
+ }
103
+ ```
104
+
105
+ ## Theming Pitfalls
106
+
107
+ ### Never hardcode colors after palette generation
108
+ Once a palette or theme exists, use `get_color` and palette-backed CSS custom properties such as `<resolved-palette-token-reference>` or semantic CSS variables derived from them. Do not leave raw hex values in component styles, theme overrides, or one-off CSS rules unless the value is intentionally outside the theme system.
109
+
110
+ ### Compound components require child theming
111
+ `igc-select`, `igc-combo`, `igc-date-picker`, and `igc-date-range-picker` are compound components. Follow the related-theme chain returned by `get_component_design_tokens` instead of styling only the parent selector.
112
+
113
+ ### Component theme functions
114
+ For core UI component theming, prefer `create_component_theme` and apply the returned theme block as generated by the MCP server.
115
+
116
+ ### Grid theming is package-specific
117
+ `igniteui-grid-lite` and the advanced grid packages do not map to Angular's `igx-grid__*` internal class structure. Use `get_component_design_tokens("grid")`, the exact grid package docs, and exposed tokens or parts for the package present in the workspace.
118
+
119
+ ### Read luminance warnings from palette generation
120
+ If palette generation returns a luminance warning for a generated surface, do not ignore it. If the design needs multiple surface depths, use `create_custom_palette` or define semantic CSS variables such as `--surface-1` and `--surface-2` in the main stylesheet instead of relying on a single generated surface color.
121
+
122
+
123
+ ## Dark Theme Specifics
124
+
125
+ ### Use the resolved dark variant for dark themes
126
+ If the project uses pre-built CSS themes, import the dark variant that matches the chosen design system in the app entry point:
127
+ ```ts
128
+ import 'igniteui-webcomponents/themes/dark/material.css';
129
+ ```
130
+
131
+ ### CSS custom properties for dark panels
132
+ When the design uses multiple dark surface depths (panels, sidebars, cards on a dark background), define reusable semantic tokens using palette references or values derived from the design intent:
133
+
134
+ ```css
135
+ :root {
136
+ --surface-primary: <resolved-surface-primary-token>;
137
+ --surface-secondary: <resolved-surface-secondary-token>;
138
+ --accent-strong: <resolved-accent-token>;
139
+ --text-primary: <resolved-text-primary-token>;
140
+ --text-secondary: <resolved-text-secondary-token>;
141
+ }
142
+ ```
143
+
144
+ If palette generation returns a single surface color that does not cover all depth levels visible in the design, define additional surface tokens (`--surface-1`, `--surface-2`, etc.) for each distinct depth.
145
+
146
+ ### Use `::part(...)` only when tokens are not enough
147
+ When a visual adjustment goes beyond component design tokens, target documented `::part(...)` selectors from the current component docs or source. Scope the selector to the smallest practical wrapper so the override stays local to the generated view.
@@ -1,6 +1,6 @@
1
1
  ---
2
2
  name: igniteui-wc-integrate-with-framework
3
- description: Integrate igniteui-webcomponents into React, Angular, Vue, or vanilla JS applications with framework-specific configurations
3
+ description: Integrate Ignite UI Web Components packages into React, Angular, Vue, or vanilla JS applications with framework-specific configurations
4
4
  user-invocable: true
5
5
  ---
6
6
 
@@ -8,6 +8,27 @@ user-invocable: true
8
8
 
9
9
  This skill helps users integrate Ignite UI Web Components into their application. It detects the framework or platform in use and loads the appropriate step-by-step integration reference.
10
10
 
11
+ ## Before You Answer
12
+
13
+ - Choose the package first, then load the framework reference.
14
+ - Do not assume every setup flow uses `igniteui-webcomponents`.
15
+ - If the required package is not present in `package.json`, add or install the correct Ignite UI dependency first. Absence from `package.json` does not mean the package is invalid.
16
+
17
+ ### Package Routing
18
+
19
+ | Component family | Package |
20
+ |---|---|
21
+ | General UI components | `igniteui-webcomponents` |
22
+ | Advanced grids | `igniteui-webcomponents-grids` (trial) `@infragistics/igniteui-webcomponents-grids` (licensed) |
23
+ | Grid Lite | `igniteui-grid-lite` |
24
+ | Dock Manager | `igniteui-dockmanager` (trial) `@infragistics/igniteui-dockmanager` (licensed) |
25
+ | Charts | `igniteui-webcomponents-charts` (trial) `@infragistics/igniteui-webcomponents-charts` (licensed) |
26
+
27
+ If the request only says "grid", infer the package from the requested features:
28
+
29
+ - Use `igniteui-webcomponents-grids` for editing, paging, sorting, filtering, summaries, grouping, hierarchical data, or pivot features.
30
+ - Use `igniteui-grid-lite` for lightweight tabular data.
31
+
11
32
  ## Example Usage
12
33
 
13
34
  - "How do I use igniteui-webcomponents in my React app?"
@@ -1,5 +1,7 @@
1
1
  # Integrating Ignite UI Web Components — Angular
2
2
 
3
+ > Package note: This page shows the default setup for `igniteui-webcomponents`. If the routing step selected `igniteui-webcomponents-charts`, `igniteui-webcomponents-grids`, `igniteui-grid-lite`, or `igniteui-dockmanager`, replace the package-specific install, import, and registration steps below with that package's setup instead of the default one.
4
+
3
5
  ## Installation
4
6
 
5
7
  ```bash
@@ -11,6 +11,8 @@ React integration uses the **`igniteui-react`** package, which provides React-na
11
11
 
12
12
  Components use the `Igr` prefix (e.g. `IgrButton`, `IgrInput`, `IgrCombo`).
13
13
 
14
+ > Package note: This page shows the default React wrapper setup for general UI components. If the routing step selected `igniteui-webcomponents-charts`, `igniteui-webcomponents-grids`, `igniteui-grid-lite`, or `igniteui-dockmanager`, do not reuse the `igniteui-react` and `Igr*` guidance below as-is; switch to the selected package's setup instead.
15
+
14
16
  ### Installation
15
17
 
16
18
  ```bash
@@ -1,5 +1,7 @@
1
1
  # Integrating Ignite UI Web Components — Vanilla JavaScript / HTML
2
2
 
3
+ > Package note: This page shows the default setup for `igniteui-webcomponents`. If the routing step selected `igniteui-webcomponents-charts`, `igniteui-webcomponents-grids`, `igniteui-grid-lite`, or `igniteui-dockmanager`, replace the package-specific install, import, and registration steps below with that package's setup instead of the default one.
4
+
3
5
  ## Installation
4
6
 
5
7
  ```bash
@@ -1,5 +1,7 @@
1
1
  # Integrating Ignite UI Web Components — Vue 3
2
2
 
3
+ > Package note: This page shows the default setup for `igniteui-webcomponents`. If the routing step selected `igniteui-webcomponents-charts`, `igniteui-webcomponents-grids`, `igniteui-grid-lite`, or `igniteui-dockmanager`, replace the package-specific install, import, and registration steps below with that package's setup instead of the default one.
4
+
3
5
  ## Installation
4
6
 
5
7
  ```bash
@@ -2,7 +2,7 @@
2
2
  "servers": {
3
3
  "igniteui-cli": {
4
4
  "command": "npx",
5
- "args": ["-y", "igniteui-cli@next", "mcp"]
5
+ "args": ["-y", "igniteui-cli", "mcp"]
6
6
  },
7
7
  "igniteui-theming": {
8
8
  "command": "npx",
@@ -1,14 +1,16 @@
1
1
  import js from '@eslint/js'
2
2
  import globals from 'globals'
3
3
  import tseslint from 'typescript-eslint'
4
+ import { configs as litConfigs } from 'eslint-plugin-lit';
4
5
  import { defineConfig, globalIgnores } from 'eslint/config'
5
6
 
6
7
  export default defineConfig([
7
- globalIgnores(['dist']),
8
- {
9
- files: ['**/*.{js,ts}'],
8
+ globalIgnores(['dist']),
9
+ {
10
+ files: ['**/*.{js,ts}'],
10
11
  extends: [
11
12
  js.configs.recommended,
13
+ litConfigs['flat/recommended'],
12
14
  tseslint.configs.recommended
13
15
  ],
14
16
  languageOptions: {
@@ -11,7 +11,7 @@
11
11
  <body class="ig-scrollbar">
12
12
  <app-root></app-root>
13
13
 
14
- <script type="module" src="./dist/src/index.js"></script>
14
+ <script type="module" src="./src/index.ts"></script>
15
15
  </body>
16
16
 
17
17
  </html>