[Layout] Should Box render interactive elements?

[yurm04]

In rebuilding the Tag component I've run into issues with rebuilding with the button and link components in the system. We have two unstyled components UnstyledButton and UnstyledLink that we wanted to use to build Tag with, but could not find a good way to get all the styling we needed with the new foundational layout components. The next thought was to rebuild these unstyled components with Box. To do this Box now needs to render an a or button element when passed to the as prop. This approach now deviates from the original purpose of Box as just a purely presentational component. Some thoughts/considerations:

• In order for Unstyled link and button to render a and button from Box I added these to the as prop of Box. Are we ok with exposing this in the Box API? What do we have to do to make a Box button or link work the way we want (accessibility, etc.) when accessed directly by the user instead of through UnstyledLink and UnstyledButton?
• Now that a and button can be rendered for Box we need to allow for interaction styling ex. hover, focus, etc. Probably a lot of other styling props we need to support everything that Tag off mainline styling did
• The layouts for Tag that renders links and spans is still not horizontally aligning. See pictures
• How do we make typescript happy with a Box needing a and button props/attributes?

branch to prototype

[laurkim]

Thanks for sharing all of the considerations with this approach 👍
While I'm not against Box supporting a or button element types, I do think supporting button especially adds a lot more complexity to Box than our original intent for it to be a way to access our design tokens. With these new element types, we'd have to support events (i.e., click, key, etc) and the interaction states, like you mentioned. I'm all for adding the various aria attributes for accessibility purposes (👏) to Box that UnstyledLink and UnstyledButton has.

If we decide to move forward with these updates to Box, I think we just have to be sure to update messaging around Box so that it's no longer emphasized as a way to just access our design tokens.

[kyledurand]

My gut feel after poking around the code is to not use Box, or our Unstyledcomponents. The two would have to be so intertwined that the complexity doesn't make it worth it.

Another big reason is that UnstyledLink and UnstyledButton both accept a className prop by nature. If we allowed className to be passed to Box, even if it were just on interactive elements, would defeat the purpose of what Box was designed for.

What if we built a new forwardRef components specifically for interactions? If we build these well we might eventually replace UnstyledLink, UnstyledButton? Any duplication between new components and existing could be abstracted into shared types / utilities

[aveline]

I think this is a good approach to explore. Better to have smaller pieces that can be combined rather than a massive and complex Box component.