Questions About Toast Placement and Meta Properties

[carlosyan1807]

I encountered two issues while using the Toast component:

1. Placement Behavior

According to the @zag-js/toast documentation, it seems that the placement of a toast can be dynamically changed. However, after checking the Toaster implementation in @ark-ui/react, it appears that the placement is tied to a specific Toaster instance. This means that a single provider can only display toasts in a fixed position.

For example, consider the following use case:

• placement: "top-end" is used for high-level notifications, such as results of async requests or socket notifications.
• placement: "top" is used for lower-level messages, like clipboard copy success or selected row count.

If I understand correctly, this would require two separate global Toaster providers to handle these different placements. Is this @ark-ui the intended design?
It feels counterintuitive, as ideally, a single ToasterProvider should allow placement to be specified dynamically when creating each toast. I understand there are challenges with overlap: true, but at least with overlap: false, dynamic placement should work as expected.

---

2. Meta Properties Customization

If I understand correctly, the meta property of a toast is intended for custom content. However, I noticed that the current implementation doesn’t provide an exported interface for meta, which makes extending or customizing it inconvenient.

If we could extend it like this, it would be great:

declare module '@ark-ui/react/toast' {  
  interface ToastMeta {  
    bgColored?: boolean;  
    showIcon?: boolean;  
    showClose?: boolean;  
    showProgress?: boolean;  
  }  
}  

Currently, I find myself repeatedly using satisfies ToastMeta for each toast operation. For example:

primaryToaster.update(toastId.current, {  
  title: t(`serverCodes.${SignInFormReturnCode.SIGN_IN_SUCCESS}`),  
  type: 'success',  
  meta: { showProgress: false } satisfies ToastMeta,  
}); 

This adds a lot of boilerplate. Could this be simplified by providing a more extensible meta interface?

I’d appreciate any guidance or clarification on these points.
Thanks in advance for your help!

[cschroeter]

@carlosyan1807

Thanks for reaching out!

For your first question—yes, your assumption is correct. You need to create a Toaster for each position. The challenge lies not only in the design but also in avoiding cluttering the DOM with separate render nodes for each position. We also factored in typical usage patterns, as most apps render toasts in a single position for a more consistent user experience.

As for your second question—I’ve encountered this myself. The best solution is to use a generic to properly type your metadata. However, since this isn’t currently planned, your workaround should be fine for now.