feat(HelperClasses): add breakpoint helper classes

[tw15egan]

Closes #2435

This PR adds in classes that can be used to hide elements only at specific breakpoints. This can already be done with the 0 column span grid classes, but this specifically addresses the need for this outside of a grid.

When the element is not in a grid, I wouldn't want to use grid classes.

This is a PoC for a potential "Helper Classes" file that lives inside the utilities section of our scss package. We've gotten other requests for simple helper classes in the past, and this would give them a place to live. Would love to know what everyone thinks.

None of the classnames/filenames are set in stone and would love feedback.

For now, you can view the example in the storybook under the Helpers section at the bottom of the list.

Changelog

New

• {{new thing}}

Changed

• {{change thing}}

Removed

• {{removed thing}}

Testing / Reviewing

{{ Add descriptions, steps or a checklist for how reviewers can verify this PR works or not }}

[netlify]

✅ Deploy Preview for carbon-components-react ready!

Built without sensitive environment variables

Name	Link
🔨 Latest commit	4e16f91
🔍 Latest deploy log	https://app.netlify.com/sites/carbon-components-react/deploys/62e435334b271a000958efb1
😎 Deploy Preview	https://deploy-preview-11786--carbon-components-react.netlify.app/
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site settings.

[netlify]

✅ Deploy Preview for carbon-elements ready!

Name	Link
🔨 Latest commit	4e16f91
🔍 Latest deploy log	https://app.netlify.com/sites/carbon-elements/deploys/62e435332eb7e00009cdfa63
😎 Deploy Preview	https://deploy-preview-11786--carbon-elements.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site settings.

[tay1orjones]

I think it makes sense to have a place like this for helper classes to live. A few thoughts:

• Does it make sense to document these in an elements example instead of storybook?
• Do we need to expose these via React Components? (Assuming no)
• Should these be within a mixin (or maybe a mixin per-class?) so they're easier to compose within existing classes a product might have?

// use a single helper via mixins?
@use '@carbon/styles/scss/utilities/helper-classes';

.my-class {
  @include helper-classes.hide-at-sm();
}

// emit "hidden" helper classes and make them all available to this module via one big mixin?
@use '@carbon/styles/scss/utilities/helper-classes';

@include helper-classes.hidden();

[tw15egan]

Does it make sense to document these in an elements example instead of storybook?

I don't have a preference here, but since it lives in the style package I just put it in the storybook.

Do we need to expose these via React Components? (Assuming no)

I don't think so

Should these be within a mixin (or maybe a mixin per -class?) so they're easier to compose within existing classes a product might have?

Good thinking, I think making them available as mixins fits better with the way we ship other helper utilities. I prefer the mixin per class approach, I can push up a PR with those changes so we can take a look

[tw15egan]

@tay1orjones I've just pushed some changes to move this to its own file called hide-at-breakpoint inside the utilities file. I've also gone ahead and updated the utilities section inside our style doc to help improve the discoverability of this and other helper mixins we have in there. Let me know what you think

[tay1orjones]

One small thing, otherwise looks good to me!