Delivering utilities ☂️

[davidmenendez]

Some components, patterns, and tooling has the potential to be (re)categorized as a "utility", which is something we really haven't thought about in the past.

Cascade is a great example of something that isn't necessarily a "component" but is a utility that can be used in any number of situations. There are probably numerous helpful utilities that we have in our codebase that we can extend to users. Another good example of a common utility function that we have and could export is the hook that is used in components like ActionBar TagOverflow and TagSet for determining overflow of a list of elements in a given area.

### Tasks
- [ ] identify best way to offer these utilities (new package?)
- [ ] categorize classes of utils (component, hook, etc)
- [ ] identify initial list of hooks, components, or other code that could be extended as a utility to consumers
- [ ] refactor & convert existing utility code to an exportable format
- [ ] add tests specifically for utilities
- [ ] identify possible need for guidance or other documentation specific concerns
- [ ] identify areas with commonality and find where we can consolodate functionality (TagOverflow vs ActionBar, DelimitedList vs StringFormatter)
- [ ] deprecate redudant components and code once utility is implemented

Work In Progress.

[elycheea]

We’ve also noticed this both in our own library and in @carbon/react but these utilities can exist both in the form of hooks (or JS only) or as component utilities.

Cascade may be a “component-based [layout] utility” similar to Stack in @carbon/react. We also see a difference in ClassPrefix v. usePrefix() from their library.

@davidmenendez summarized this as:

we might want to consider different approaches. perhaps offering both. something like the component for easy use and the hook for something more customizable

Also @matthewgallo thoughts on how we could refactor TagSet and TagOverflow (as of yesterday, we’re now lumping ActionBar into this category too after the review of #6159).

I think it would be cool to have a hook that just handles all the resizing of TagSet and TagOverflow and the hook just returns the number of items that should be visible (there's more to think through there but it would allow for a more composable approach to components like those two.

[elycheea]

Doesn’t really need design but also wanted to tag @aubrey-oneal on this since I know you explored added a utilities section for the website launch (but we didn’t want to include only Cascade). Curious how you were envisioning documentation of these on the website. I imagine the needs here would differ from how we typically document components though.

[davidmenendez]

regarding the first issue

identify best way to offer these utilities (new package?)

i think a new package might be the way to go. it's a little extra overhead, but the more i think about it the more it makes sense to me. these utilities don't necessarily need to be coupled to the react components. things like calculating the overflow of a div for components like TagOverflow or TagSet has a multitude of uses outside the scope of just these components, so i think it makes sense to offer that functionality separate from the rest of the entire library.

but i acknowledge that might be overkill considering right now we necessarily have a lot of utility functions so far. i think setting it up now as it's own package would be future proofing it 🤔

[davidmenendez]

reminder: discuss during next refinement call on 11/27/24