Size Change: -22 B (0%)

Total Size: 1.25 MB

_{compressed-size-action}

It looks promising. I'm not hugely into stringly typing these variations, but I know this pattern is being favoured in other components. I like boolean props better because they can be combined (i.e. <Popover hasStickyHeader hasBorderlessHeader).

But if the variant approach is preferred, maybe the guide should have a 'sticky' variant, so that those other styles aren't left behind.

The only other option that springs to mind is making a separate ModalHeader component. I think this was done with Popover. Might be quite a lot of work, and I'm fully aware that I'm making a lot of work for you at the moment 😄

I'm not so sure. Even with this change, these uses of Modal still reference internal class names a lot. It feels like we're fighting a losing battle..

This is also my general feeling — it feels a bit like the Modal component is not very aligned with the design requirements across the app.

I'm not hugely into stringly typing these variations, but I know this pattern is being favoured in other components. I like boolean props better because they can be combined (i.e. <Popover hasStickyHeader hasBorderlessHeader).

I also agree with this point — the concept of "variant" works well when the options being represented are mutually exclusive. Daniel's example is fitting — what if the header needs to be borderless AND sticky?

On top of that, I'd also advocate for less presentational variant names than "borderless", as they make it hard to update the design of the component in the future without introducing breaking changes / deprecations.

The only other option that springs to mind is making a separate ModalHeader component. I think this was done with Popover. Might be quite a lot of work, and I'm fully aware that I'm making a lot of work for you at the moment 😄

Similarly to this idea, I also think that one way to improve the situation may be to "modularize" the Modal component (e.g into its wrapper, header, content wrapper, buttons...), so that the consumers of the component can either use the default "monolithic" Modal, or compose their own by mixing a matching the subcomponents (and/or replacing them with custom ones).

Something I wanted to ask @WordPress/gutenberg-design is if it makes sense to have a modal with a border underneath the title and a modal with none? Can we consolidate and choose one design?

In #40781 the border beneath the modal title is removed unilaterally. It's just waiting approval :)

Oh perfect @jameskoster. I think #40781 is the better direction to go in then.