Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat(chip): add component tokens #10179

Merged
merged 20 commits into from
Sep 20, 2024
Merged

feat(chip): add component tokens #10179

merged 20 commits into from
Sep 20, 2024

Conversation

alisonailea
Copy link
Contributor

@alisonailea alisonailea commented Aug 28, 2024

Related Issue: #7180

Summary

Adds tokens, e2e, and custom-theme chromatic tests. This ended up being a larger refactor to clarify internal tokens.

Chip Tokens

--calcite-chip-background-color: Specifies the background color of the component.
--calcite-chip-border-color: Specifies the border color of the component.
--calcite-chip-corner-radius: Specifies the corner radius of the component.
--calcite-chip-text-color: Specifies the text color of the component.
--calcite-chip-icon-color: Specifies the icon color of the component.
--calcite-chip-close-icon-color: Specifies the icon color of the close element of the component.
--calcite-chip-select-icon-color: Specifies the icon color of the selection element of the component.
--calcite-chip-select-icon-color-pressed: Specifies the icon color of the selection element of the component when active.

Chip Group Tokens

--calcite-chip-group-items-space: Specifies spacing between items in the component.

* @prop --calcite-chip-border-color: Specifies the border color of the component.
* @prop --calcite-chip-corner-radius: Specifies the border radius of the component.
* @prop --calcite-chip-text-color: Specifies the text color of the component.
*
Copy link
Contributor

@macandcheese macandcheese Aug 28, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we'd at the very least want to add --calcite-chip-icon-color and --calcite-chip-selection-icon-color (or whatever name) from the 7180 PR:

* @prop --calcite-chip-icon-color: Specifies the color of the component's icon property.

We can't just set --calcite-icon-color on a Calcite Chip - it has too many internally rendered icons that would be affected. The 7180 PR also had --calcite-chip-close-icon-color (and, props to control internal close button states, which it sounds like we did not want to pursue - I still think this prevents a lot of valid use cases)

Copy link
Contributor Author

@alisonailea alisonailea Aug 28, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The design pattern for calcite-chip is for icons to follow the text color. If a user wants to have a special color they can do something like calcite-chip.my-chip { --calicte-icon-color: red }. Similarly. IMO, all close sub-elements (should) have the same interaction pattern with a shared token set. Something like

--calcite-close-color
--calcite-close-background-color-hover
--calcite-close-background-color-press

@SkyeSeitz @ashetland

Copy link
Contributor

@macandcheese macandcheese Aug 28, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agreed they should be (ideally) consistently implemented when overridden - but not adding component-specific ones (even if it falls back to the global one) to the component means they won't be documented alongside all the other component tokens - wherever that doc is consumed (including places we can't manually supplement it with info about these generic "close-color" props).

Currently it seems like text-color property here also sets the selection affordance icon as well as the icon-start icon. At the very least I'd like to be able to not have this happen (which is the current behavior):

The current behavior that is available (just overriding the global css prop - changes the affordance as well as the icon, which I don't think is always preferable).

Screenshot 2024-08-28 at 1 57 43 PM

My use case for overriding an icon color is probably to match map symbology or layer display color / graphics (or something like that). So I don't think I'd want the selection icon to change as well:

Screenshot 2024-08-28 at 1 57 54 PM

@macandcheese
Copy link
Contributor

Do we want to kick off Chromatic builds for these token PR that include refactors?

…openPR/7180-chip

# Conflicts:
#	packages/calcite-components/src/components/chip/chip.scss
@github-actions github-actions bot added the enhancement Issues tied to a new feature or request. label Aug 28, 2024
@alisonailea
Copy link
Contributor Author

Do we want to kick off Chromatic builds for these token PR that include refactors?

Yes all token PRs need to pass Chromatic tests because we need to ensure they are not creating unexpected visual changes. I've done manual checks but human error is real.

Copy link
Contributor

@macandcheese macandcheese left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think the spacing props need a pass here for certain configurations:
Screenshot 2024-08-28 at 2 06 15 PM

After an inspection of the chip component in figma this adds additional internal variables to clarify what elements are changing and based on what state changes.
Also breaks out reusable .close mixin
@alisonailea alisonailea added the pr ready for visual snapshots Adding this label will run visual snapshot testing. label Sep 3, 2024
resolves some issues with internal component spacing. It also normalizes internal variables and makes future maintenance easier by breaking variables out by sub-element.
Copy link
Contributor

@macandcheese macandcheese left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good! Just some comments on token naming, and also confirming that:

  • with this set up, users can't independently control the selection affordance icon - just the "icon rendered via prop" and the close button.

Could you kick off another Chromatic build to test latest changes? Thanks!

*
* @prop --calcite-chip-background-color: Specifies the background color of the component.
* @prop --calcite-chip-border-color: Specifies the border color of the component.
* @prop --calcite-chip-corner-radius: Specifies the border radius of the component.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For the description here do we want to also use "corner radius"?

* @prop --calcite-chip-corner-radius: Specifies the border radius of the component.
* @prop --calcite-chip-text-color: Specifies the text color of the component.
* @prop --calcite-chip-icon-color: Specifies the icon color of the component.
* @prop --calcite-close-icon-color: Specifies the icon color of the close element of the component.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I realize this is "global" but it still (IMO) would be nice to scope this to the component. That way, both --calcite-close-icon-color works (at the global level) and --calcite-chip-close-icon-color (at the component level) could work, and we don't need to document non-component-scoped tokens inside a component.

Confirming we are not allowing the Chip's selection affordance to change independently of the "icon rendered from prop".

@alisonailea alisonailea removed the pr ready for visual snapshots Adding this label will run visual snapshot testing. label Sep 10, 2024
Copy link
Member

@jcfranco jcfranco left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Aside from a few comments, this looks great!

});

describe("appearance='outline'", () => {
themed(html`<calcite-chip appearance="outline" kind="neutral">Layers</calcite-chip>`, {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is kind=neutral important for this test? If so, can we rename the describe block to convey this? Otherwise, let's remove it.

--calcite-internal-chip-padding-end: var(--calcite-spacing-base);
:host([scale="s"]) {
.container {
--calcite-internal-chip-block-size: 1.5rem /* 24px */;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Instead of adding comments with the equivalent pixel size for all of these, may I suggest adding this to our extensions? It should help reduce noise, overhead, and the chance of them being overlooked when updated.

If that looks like a good path forward, we can update the extensions in a separate PR.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was doing this because these need to be replaced with the upcoming spacing tokens which will all use rems instead of px

@@ -152,3 +152,40 @@
}
}
}

@mixin close-button($size: "var(--calcite-internal-close-size, 1.5rem /* 24px */)", $padding: "0") {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sidebar: we'll need to consolidate this with the x-button mixin above. Related #6640.

box-border
font-medium;

border-radius: var(--calcite-chip-corner-radius, 9999px);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sidebar: we still need a semantic token for this fallback, right?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yes this will be coming in future updates

@jcfranco
Copy link
Member

@alisonailea Before merging, can you update the PR description with the latest component tokens?

@@ -3727,15 +3727,16 @@
}
},
"node_modules/@inquirer/core": {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you roll back the this change?

@alisonailea alisonailea added the pr ready for visual snapshots Adding this label will run visual snapshot testing. label Sep 12, 2024
@alisonailea alisonailea added pr ready for visual snapshots Adding this label will run visual snapshot testing. and removed pr ready for visual snapshots Adding this label will run visual snapshot testing. labels Sep 13, 2024
@alisonailea alisonailea removed the pr ready for visual snapshots Adding this label will run visual snapshot testing. label Sep 13, 2024
@alisonailea alisonailea added the pr ready for visual snapshots Adding this label will run visual snapshot testing. label Sep 16, 2024
@alisonailea alisonailea added pr ready for visual snapshots Adding this label will run visual snapshot testing. and removed pr ready for visual snapshots Adding this label will run visual snapshot testing. labels Sep 19, 2024
@alisonailea alisonailea merged commit ff82570 into dev Sep 20, 2024
13 checks passed
@alisonailea alisonailea deleted the astump/7180-chip branch September 20, 2024 17:27
benelan added a commit that referenced this pull request Sep 20, 2024
* origin/dev:
  feat(chip): add component tokens (#10179)
  feat(avatar): add component tokens (#10280)
  fix(popover): update focus trap elements on mutation observer (#10357)
  fix(action-pad): update layout on action-group elements slotted after initialization (#10355)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement Issues tied to a new feature or request. pr ready for visual snapshots Adding this label will run visual snapshot testing.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants