feat(badge): s2 styling and render

[castastrophe]

Description

Using the approach outlined in the styling RFC; brought in the existing S2 stylings from the CSS spectrum-two branch and noted any questions, concerns, and API implications as comments on this PR.

Focused on the badge component.

Motivation and context

Related issue(s)

• CSS-1269

Screenshots (if appropriate)

---

Author's checklist

• I have read the CONTRIBUTING and PULL_REQUESTS documents.
• I have reviewed at the Accessibility Practices for this feature, see: Aria Practices
• I have added automated tests to cover my changes.
• I have included a well-written changeset if my change needs to be published.
• I have included updated documentation if my change required it.

---

Reviewer's checklist

• Includes a Github Issue with appropriate flag or Jira ticket number without a link
• Includes thoughtfully written changeset if changes suggested include patch, minor, or major features
• Automated tests cover all use cases and follow best practices for writing
• Validated on all supported browsers
• All VRTs are approved before the author can update Golden Hash

[changeset-bot]

⚠️ No Changeset found

Latest commit: 5b47c1c

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[github-actions]

📚 Branch Preview

• Documentation Site
• Storybook

🔍 Visual Regression Test Results

When a visual regression test fails (or has previously failed while working on this branch), its results can be found in the following URLs:

• Spectrum | Light | Medium | LTR
• Spectrum | Dark | Large | RTL
• Express | Light | Medium | LTR
• Express | Dark | Large | RTL
• Spectrum-two | Light | Medium | LTR
• Spectrum-two | Dark | Large | RTL
• High Contrast Mode | Medium | LTR

Deployed to Azure Blob Storage: pr-5718

If the changes are expected, update the current_golden_images_cache hash in the circleci config to accept the new images. Instructions are included in that file.
If the changes are unexpected, you can investigate the cause of the differences and update the code accordingly.

[github-actions]

Tachometer results

Currently, no packages are changed by this PR...

[castastrophe]

I updated the ternary to use when instead but let me know if there's a reason not to use that here.

[graynorton]

👍 Since the 2nd-gen render() method is conceptually free to diverge from the 1st-gen method in whatever way is useful (provided there is no impact on the component API), there's no reason not to opt for when here.

[castastrophe]

I tested adding this class to the slot itself and it didn't render padding correctly. Maybe just a case of needing the appropriate display settings but I didn't dig into it too much. Would be good to have a standard "best practice" in place for whether we want to wrap slots to apply styles or style slot containers directly.

[graynorton]

Yes, it looks like adding a rule to the component styles that sets display: block; on the slot also works.

I think in general it would be better to avoid systematically wrapping slots for styling purposes.

[castastrophe]

This seems to me to be how the @Property works by default. I don't see any regressions when I simplify this but let me know if I've missed a nuance here.

[graynorton]

At a glance, I think you're right—at least, I can't immediately see why this property would need a bespoke getter and setter.

That said, the aim of the Barebones milestone is to avoid any changes not strictly related to migrating these components to the new architecture, so I think the best course of action here would be to add a @todo comment rather than making a change in this PR.

[castastrophe]

Separating out the semantic variants from the color variants helps us in Storybook (and possibly down the road) because only semantic variants support outline styling.

[graynorton]

Yes, this seems like a good idea!

[castastrophe]

This re-exports the const with the addition of the new colors.

[graynorton]

Yes, we definitely need to define a constant representing the full set of S2 colors. As I mentioned in an earlier comment, I've done some additional exploration into patterns for managing differences in S1 & S2 types, which I'll put in a separate PR (to land after this one).

[castastrophe]

I'm not sure if I need to redefine this since technically it's the same but the content of the BADGE_VARIANTS has changed so I went ahead and did that.

[castastrophe]

@rubencarvalho Do you know how that works in Typescript? Would it calculate the value of BadgeVariant at the time of use based on the new definition of BADGE_VARIANTS?

[graynorton]

Yes, as far as TypeScript is concerned, the type defined in this module is completely different from the type defined in the core module, though they share the same name, so it would in fact need to be exported here.

Again, though, I'll make a separate follow-on PR to propose some patterns for managing S1 and S2 types.

[castastrophe]

Since this doesn't have a render, should we define these only on the render layer?

[graynorton]

I think it's better to define them here on the base class, since these slots are effectively part of the component architecture dictated by the base class (i.e., any concrete implementation building on this base class will need to include the slots), and the base class includes the mixin functionality associated with the slots.

[aramos-adobe]

@castastrophe The S2 addition of these are sooooo lovely!! I'd love to contribute to this!!

[castastrophe]

@rubencarvalho Initially I started updating these assets per the S2 guidelines before I realized this is the base class being imported into S1 components as well. Would it make sense to hoist this folder to sit between the first- and second-get folders so it's clear that it's a shared resource?

[graynorton]

I think the key here is just going to be to make it clear (via docs and other means) that the S1/S2 distinction is not the same as the 1st-gen/2nd-gen distinction.

The core library is in 2nd-gen because it, along with 2nd-gen SWC, is going to use our 2nd-gen tooling and infrastructure, and because we have a sense that the core layer may prove useful even after the 1st-gen to 2nd-gen transition is complete. (If it does not, we can remove it when we eventually stop supporting 1st-gen.)

As a layer of the architecture that explicitly supports both S1 and S2, I think it's actually OK if core ends up including some type definitions that are S1- and S2-aware, allowing us to manage the differences in one place. I've done some further exploration of what this might look like that I'll put in a separate PR.

[graynorton]

@castastrophe Thank you for blazing the trail here and getting the S2 Badge rendering and styling migrated!

The patterns you explored around the nuances of the factoring between the abstract base components in core and the concrete rendering components in 1st- and 2nd-gen SWC, and for managing type differences between the S1 and S2 components, were also very informative. 🙏

As I mentioned in a few specific review comments, what we'd like to do is go ahead and merge this PR into the barebones branch (along with your work on ProgressCircle), after which I'll make a follow-on PR proposing some general patterns for use on the remaining Barebones components.

I've gone ahead and approved this PR; no need to make any further changes on this branch as far as I'm concerned.

[graynorton]

Yes, this seems like a good idea!

[graynorton]

I think the key here is just going to be to make it clear (via docs and other means) that the S1/S2 distinction is not the same as the 1st-gen/2nd-gen distinction.

The core library is in 2nd-gen because it, along with 2nd-gen SWC, is going to use our 2nd-gen tooling and infrastructure, and because we have a sense that the core layer may prove useful even after the 1st-gen to 2nd-gen transition is complete. (If it does not, we can remove it when we eventually stop supporting 1st-gen.)

As a layer of the architecture that explicitly supports both S1 and S2, I think it's actually OK if core ends up including some type definitions that are S1- and S2-aware, allowing us to manage the differences in one place. I've done some further exploration of what this might look like that I'll put in a separate PR.

[graynorton]

👍 Since the 2nd-gen render() method is conceptually free to diverge from the 1st-gen method in whatever way is useful (provided there is no impact on the component API), there's no reason not to opt for when here.

[graynorton]

Yes, it looks like adding a rule to the component styles that sets display: block; on the slot also works.

I think in general it would be better to avoid systematically wrapping slots for styling purposes.

[graynorton]

I think it's better to define them here on the base class, since these slots are effectively part of the component architecture dictated by the base class (i.e., any concrete implementation building on this base class will need to include the slots), and the base class includes the mixin functionality associated with the slots.

[graynorton]

At a glance, I think you're right—at least, I can't immediately see why this property would need a bespoke getter and setter.

That said, the aim of the Barebones milestone is to avoid any changes not strictly related to migrating these components to the new architecture, so I think the best course of action here would be to add a @todo comment rather than making a change in this PR.

[graynorton]

Yes, we definitely need to define a constant representing the full set of S2 colors. As I mentioned in an earlier comment, I've done some additional exploration into patterns for managing differences in S1 & S2 types, which I'll put in a separate PR (to land after this one).

[graynorton]

Yes, as far as TypeScript is concerned, the type defined in this module is completely different from the type defined in the core module, though they share the same name, so it would in fact need to be exported here.

Again, though, I'll make a separate follow-on PR to propose some patterns for managing S1 and S2 types.

[graynorton]

I think, since we're not going to be releasing any S2 components for a while (even in preview form), we might as well take the conservative approach and not include any real Figma links for the time being.