Spectrum 2 Knowledge

[BMCwebdev]

Hey there. So only recently have I started looking at the Spectrum 2 codebase. Having been building our company design system based on React Aria Components, I am really interested in some of the patterns that you have established.

On example: I am looking at how you built your Dialog component, and the pattern of using context like this

<Provider
  values={[
    [ImageContext, {hidden: true}],
    [HeadingContext, {isHidden: true}],
    [HeaderContext, {isHidden: true}],
    [ContentContext, {isHidden: true}],
    [FooterContext, {styles: footer}],
    [ButtonGroupContext, {isHidden: props.isDismissible, styles: buttonGroup, align: 'end'}]
  ]}>

I find this really interesting as a way to place reusable content into correct sections within the larger component. I would love to read more on how you came to land on this pattern. Why go with this pattern vs something like DialogHeader, DialogTitle, etc? Dialog is the only component I see in S2 that is using it, so perhaps you are not sold on it yet? I see Provider is used heavily, mostly for styling it seems?

Anyways, yes, I would love to learn more about your discovery process. Any chance there is someplace to do that?

Thanks!

[snowystinger]

Thanks for the interest. This has mostly evolved over time as the need has arisen. Our initial thinking was outlined here https://github.com/adobe/react-spectrum/blob/main/rfcs/2019-v3-slots.md and here https://github.com/adobe/react-spectrum/blob/main/rfcs/2019-v3-semantic-elements.md

When we built our Dialog in the V3 vs S2 version, we did it all with grid layout as outlined there. This came with some interesting limitations we didn't anticipate. Namely that grids, while extremely flexible for positioning like this, do cause arbitrary alignment between possibly unrelated elements. Because of that, it can be useful to mix and match grids/flex and have some nesting, which means all the semantic elements can't be siblings anymore, which was our original hope.

We thought then that maybe we'd need to go the way that you mentioned, having DialogHeader/DialogTitle/etc and people would need to learn how to put the dom structure together correctly, which would be brittle.

Another option we considered was making each element a prop, so <Dialog header={<Header/>} body={<Content/> ... but that would go against our original goal as well.

We landed on this pattern as a way to keep our original goal of being able to place components inside without memorising a complex dom structure and keep reusable consistent "Content" components. It also keeps us closer to the existing v3 API, minimising breaking changes.

We may use it in other components, but haven't had a need to yet.

A related discussion:
Question about slot layouts and isHidden pattern in S2 Dialog components

[BMCwebdev]

This is great stuff, thank you for sharing. Reading up now.