Toast Stack as a composable element

[hunterloftis]

Many Shoelace components compose others, or are composed of others, in ways that "just work." (eg: Menu, Dropdown, Select, Button, Icon...)

Alert's "toast" functionality deviates from this with a predefined singleton that depends on CSS at the page level. That breaks functionality like JS-importable themes.

Would you consider a composition story like this?

<sl-toast-stack>
  <sl-alert variant="primary" duration="3000" closable>
    <sl-icon slot="icon" name="info-circle"></sl-icon>
    <strong>This is super informative</strong><br />
    You can tell by how pretty the alert is.
  </sl-alert>
  <sl-alert variant="success" duration="3000" closable>
    <sl-icon slot="icon" name="check2-circle"></sl-icon>
    <strong>Your changes have been saved</strong><br />
    You can safely exit the app now.
  </sl-alert>
</sl-toast-stack>

(To be activated the same way as today: alert.toast())

That would allow a broader variety of apps & layouts to leverage the toast stack functionality, and I think it would map well to Shoelace's other idioms. It would also let developers avoid this action-at-a-distance behavior:

The toast stack is a fixed position singleton element created and managed internally by the alert component. It will be added and removed from the DOM as needed when toasts are shown.

A lower-impact variant of this idea is:

Allow an optional toastStack to be passed into the toast() function. That way, default/today's usage continue to leverage the singleton, but a developer could simply:

alert.toast(myCustomToastStack);

[claviska]

I'm definitely open to this!

That breaks functionality like #438 (comment).

Can you elaborate on this statement? As it stands, Shoelace requires the light and/or dark theme since most components use those design tokens. There are a small number of utility styles that get included, two of which are related to the toast stack.

It's not clear to my what the benefit of moving this to a component is, especially if it's only used once per page. Is the goal to allow multiple toast stacks to be present on the page? Or are we mostly looking to remove these utility styles by componentizing the toast stack?

Thanks for clarifying!

[hunterloftis]

Awesome!

Can you elaborate on this statement? As it stands, Shoelace requires the light and/or dark theme since most components use those design tokens. There are a small number of utility styles that get included, two of which are related to the toast stack.

Certainly - I'm using Shoelace to build an app composed of web components (everything is a component, top-to-bottom). At the page level, no CSS is included. Each component leverages Shoelace's design tokens, to keep the whole design coherent. Since the JS bundle uses Shoelace's .js exports from /dist, if I did include top-level CSS on the page, it would essentially be duplicated.

Since the current implementation of the toast stack appends to light DOM and expects the top-level document to include utility CSS globally, none of the design tokens that sl-alert depends on are available, so any .toast()-generated alerts are rendered unstyled.

Moving to a component would:

• Allow Shoelace's toasts to work in bundled environments where Shoelace's CSS is not globally available
• Allow components that use Shoelace components themselves to render toasts, without adding requirements to the end-user's HTML
• Allow customization of toast stacks, such as keeping them from breaking an app's layering (like intruding over a modal dialog by appending to body), changing their styling & alignment (shadows, underlays), and... I guess... having multiple toast stacks if you want, although that's not something that I'd encourage.
• Avoid singletons & implicit global state

That said, right now I'm working around it (by essentially implementing a toast-stack component 😁), and it's not a huge deal. I partly opened this discussion because so far I keep running into things where I'm like, "if only I could swap out the suffix icon in this sl-input with a trashcan icon-button so 'delete' could be an integrated action... oh look, I can!" ... I've come to expect Shoelace to be super-modular, and this is the first edge I've run into where it isn't.