chore: Add icon size and stroke width props#4514
Conversation
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #4514 +/- ##
==========================================
- Coverage 97.42% 97.41% -0.02%
==========================================
Files 939 939
Lines 29645 29708 +63
Branches 10772 10800 +28
==========================================
+ Hits 28883 28939 +56
- Misses 715 722 +7
Partials 47 47 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
- Add x-small and large icon size variants to complement existing sizes - Create IconSizes component showcasing all icon size options (x-small, small, normal, medium, big, large) - Update icon-scale-props page to display icon sizes in typography headings with size labels - Refactor icon size display from static list to dynamic mapped component - Add delivery method form field example to ButtonsInputsDropdowns section - Remove section separator comments for cleaner code organization - Update icon provider and icon interfaces to support new size variants - Update icon mixins and styling for new size tokens - Add x-small and large size tokens to style dictionary borders and sizes - Update token name utilities and metadata for new size variants - Update all related snapshot tests to reflect new icon size options
2f5eb33 to
1d370b1
Compare
- Add `sizes` prop to IconProvider to customize icon dimensions per size variant - Add `strokeWidths` prop to IconProvider to customize stroke widths per size variant - Support scoped overrides at any level of the component tree - Update IconProvider internal implementation to apply size and stroke-width overrides - Update Icon internal implementation to respect provider overrides - Add comprehensive API proposal documentation with usage examples and design rationale - Update icon provider dev page to demonstrate new scale props functionality - Update icon-related dev pages (custom SVG, icons list, text align) to reflect changes - Update snapshot tests to reflect new IconProvider interface and behavior
- Replace numeric IDs ('1', '2', '3', etc.) with semantic prefixed IDs ('action-1', 'action-2', 'action-3', etc.)
- Update all nested child node IDs to follow the new naming convention
- Update expandedItems state initialization to use new semantic IDs
- Improve ID clarity and maintainability in icon-scale-props demo page
|
|
||
| function TableAndCards() { | ||
| const [selectedTableItems, setSelectedTableItems] = useState([tableItems[2]]); | ||
| const { items, collectionProps } = useCollection(tableItems, { sorting: {} }); |
There was a problem hiding this comment.
nit: Do we really need sorting and selection in this demo page?
There was a problem hiding this comment.
Good point — switched to generateItems + columnsConfig from the shared table configs, which removes the custom selection/sorting setup.
| enableTokenGroups={true} | ||
| expandToViewport={true} | ||
| filteringAriaLabel="Find distributions" | ||
| i18nStrings={{ |
There was a problem hiding this comment.
We can use I18nProvider instead. The simplest option is to use the SimplePage template as such:
<SimplePage title="Icon scale overview" i18n={{}} screenshotArea={{}}>
...
</SimplePage>
There was a problem hiding this comment.
the same applies to other i18nStrings on this page
There was a problem hiding this comment.
Thanks for the suggestion. Removed the verbose i18nStrings from PropertyFilter and SplitPanel for now. Will look into adopting SimplePage / I18nProvider as a follow-up.
| children?: ConnectorLinesItem[]; | ||
| } | ||
|
|
||
| const connectorLinesItems: ConnectorLinesItem[] = [ |
There was a problem hiding this comment.
nit: why do we call these connectorLinesItems and not treeItems, and why is a custom type needed for these?
There was a problem hiding this comment.
Good catch — renamed to treeItems and TreeItem. The custom interface was unnecessary since the shape is the same as what TreeView expects.
| })} | ||
| getItemId={item => item.id} | ||
| getItemChildren={item => item.children} | ||
| onItemToggle={({ detail }) => |
There was a problem hiding this comment.
nit: for the purposes of this demo I think we can remove the interactivity from the tree-view, wdyt?
There was a problem hiding this comment.
Done — removed the useState and onItemToggle handler, expandedItems is now a plain constant.
| // Split panel state | ||
| const [splitPanelOpen, setSplitPanelOpen] = useState(true); | ||
|
|
||
| const sizeXSmallValue = parseFloat(iconSizeXSmall); |
There was a problem hiding this comment.
nit: this value is used in a single place - you can call parseFloat before passing it to the provider in order to avoid creation of a new var here
There was a problem hiding this comment.
Done — removed all the intermediate *Value variables and inlined parseFloat() directly in the IconProvider props.
|
|
||
| &.size-#{$name} { | ||
| inline-size: $size; | ||
| /* stylelint-disable-next-line custom-property-pattern */ |
There was a problem hiding this comment.
This rule exists in order to avoid using un-hashed css props that consumers can start relying on in their code. See approach used for style API (/internal/generated/custom-css-properties) - can use use it here, too?
There was a problem hiding this comment.
Good call. Added iconSizeOverride, iconStrokeWidthOverride, and iconStrokeScale to
custom-css-properties.js, regenerated the map, and updated mixins.scss to use the hashed variables via @use '../internal/generated/custom-css-properties' as custom-props. Also updated internal.tsx and the tests to use the map. No more stylelint-disable comments needed.
fe62fc1 to
16d2910
Compare
9b49b0d to
5c73570
Compare
Description
This PR adds:
1. New sizes and strokeWidths props on IconProvider:
Extend the existing IconProvider component with two new props — sizes and strokeWidths — that allow overriding icon dimensions and stroke widths at any level of the component tree.
In a nutshell, this proposal enables icon size and stroke-width customization by overriding the inline size and stroke-width of both the icon SVG and its wrapper element via the existing IconProvider.
Because the icon-provider already establishes a predictable scoping mechanism, icon sizes can be flexibly adjusted at different levels of the UI while maintaining consistent behavior.
This approach:
2. A new x-small icon size variant (12px) for the icon component:
While it’s not currently used by any existing components, it supports future use cases we’ve already identified, such as icons inside badge components and icons used in button groups within prompt inputs.
How has this been tested?
Review checklist
The following items are to be evaluated by the author(s) and the reviewer(s).
Correctness
CONTRIBUTING.md.CONTRIBUTING.md.Security
checkSafeUrlfunction.Testing
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.