feat(progress-bar): add recipe and tokens#31087
feat(progress-bar): add recipe and tokens#31087thetaPC wants to merge 20 commits intoionic-modularfrom
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
| subtle?: boolean; | ||
| } | ||
|
|
||
| export function ionColor(name: string, variation: string, options: IonColorOptions = {}): string { |
There was a problem hiding this comment.
This function is originally added through the badge PR but it's still in progress so I added it here to not be blocked.
ShaneK
left a comment
ShaneK
left a comment
There was a problem hiding this comment.
Looking good! Just a couple things I noticed but I could be off base
| }, | ||
|
|
||
| IonProgressBar: { | ||
| height: 'var(--token-scale-100, var(--ion-scaling-100))', |
There was a problem hiding this comment.
var(--token-scale-100, var(--ion-scaling-100)) wraps a --token-* variable I couldn't find defined anywhere in the repo. Same on lines 532 and 538 with --token-round-xs and --token-rectangular-xs. Is this intentional scaffolding for the ionic modular work? If not, the other component entries in this file (IonChip, IonSpinner, IonItemDivider) reference --ion-* directly, so maybe this should too? Not sure.
There was a problem hiding this comment.
Ah, I meant to add a comment here.
You're right that --token-* variables don't exist in this repo. They're defined in the OS project. The intent was to make it easier for the components team to adopt the Ionic token file in the future by referencing --token-* first with --ion-* as a fallback. The components team can override values at the token level without having to make as many changes here. If we approve this change, I plan to go back to the others and add the --token-* variables through a different PR. I figured if it gets denied, then no need to do that extra work. 😅
| ); | ||
| } | ||
|
|
||
| :host(.progress-bar-solid) .buffer-circles { |
There was a problem hiding this comment.
When progress-bar-solid is set, the render function applies ion-hide (display: none !important) to the parent .buffer-circles-container, so this .buffer-circles rule inside it can't paint. Is the plan to drop the ion-hide toggle later and let CSS handle the hide, or is this rule dead?
There was a problem hiding this comment.
Good catch! 6a19f57
It sounds like we will keep ion-hide but just a different class name.
| class={{ 'buffer-circles-container': true, 'ion-hide': finalBuffer === 1 }} | ||
| class={{ | ||
| 'buffer-circles-container': true, | ||
| 'buffer-circles-container-hidden': finalBuffer === 1, |
There was a problem hiding this comment.
I added this class now so it would be easier to replace when we remove ion-hide.
2 participants
Issue number: internal
What is the current behavior?
Component styles for
ion-progress-barare fragmented across multiple files (native andionic). Themdandiosthemes rely on the native styles. Developers were restricted to those themes and how those themes structured the logic and styles.What is the new behavior?
progress-bar.scssfile that consumes CSS variables, ensuring a single source of truth for component logic.IonProgressBartype and tokens to use an element-first hierarchy ({type}.{element}.{state}, e.g.,determinate.progress.default.background). This provides predictability and consistency with the rest of the system.progress-bar.interfaces.tswith reusable types for the recipe and config.ios,md, andionictheme files.roundandrectangularshape variants with per-theme defaults (roundforiosandionic,rectangularformd).buffer = 1), including separate rules for the buffer bar and buffer circles.progress-bar-type-determinate/progress-bar-type-indeterminate) to prevent cross-type style bleed.--backgroundand--progress-backgroundwith a structured set of semantic variables (e.g.,--ion-progress-bar-determinate-progress-default-background).Does this introduce a breaking change?
This PR introduces breaking changes to how
IonProgressBaris styled.Migration Path:
Token Updates: Update any custom theme configurations to match the new nested structure.
CSS Variable Replacements:
--backgroundand--progress-backgroundhave been removed. Use the new token structure instead:--background→IonProgressBar.determinate.buffer.bar.default.background(or the indeterminate equivalent)--progress-background→IonProgressBar.determinate.progress.default.background(or the indeterminate equivalent)If per-component customization is needed, the CSS variables can be used directly (e.g.,
--ion-progress-bar-determinate-progress-default-background).Host class names: The type classes on the host element have been renamed to include the prop name:
.progress-bar-determinate→.progress-bar-type-determinate.progress-bar-indeterminate→.progress-bar-type-indeterminateTheme classes: Remove any instances that target the theme classes:
ion-progress-bar.md,ion-progress-bar.ios.Other information
Previews:
Previews: