Feature request : Support multiple Toasters with specifying target toaster per toast

[abiswas97]

Similar to #132, but for multi-Toaster support rather than individual toast position.

In my use case, I have a global Toaster for most app level notifications. But, I would also like to support a separate notification set just for another key component. For example, notifications for the page vs notifications for a drawing canvas. Would this potentially be a feature?

[zettadam]

This is a must-have feature if you want toasts rendered above the top layer with <dialog /> element. Without it, sonner is not worth considering.

[emilkowalski]

Similar to #132, but for multi-Toaster support rather than individual toast position.

In my use case, I have a global Toaster for most app level notifications. But, I would also like to support a separate notification set just for another key component. For example, notifications for the page vs notifications for a drawing canvas. Would this potentially be a feature?

Can you clarify why you need a separate one?

[emilkowalski]

This is a must-have feature if you want toasts rendered above the top layer with <dialog /> element. Without it, sonner is not worth considering.

I don't understand your point, can you clarify?

[brandonmcconnell]

@emilkowalski I'm just now coming across this feature, but this is a crucial feature in many of my apps. Would love to reopen if possible.

In one of my projects which uses fkhadra/react-toastify, we use a default ToastContainer (toaster) at the app level that renders all toasts without a specified containerId, and we have another ToastContainer inside our Dialog component that renders toasts with its containerId in the corner of the dialog instead of the corner of the window/viewport.

So when using only one ToastContainer, you use this simple syntax:

import { ToastContainer } from 'react-toastify';

function Main() {
  return (
    <>
      <ToastContainer />
      <OtherComponent />
    </>
  );
}

function OtherComponent() {
  return (
    <button onClick={() => toast("toast content")}>Trigger toast</button>
  );
}

When using more than one ToastContainer, you use the enableMultiContainer prop on every ToastContainer and apply an id to any you wish:

import { ToastContainer } from 'react-toastify';

function Main() {
  return (
    <>
      <ToastContainer enableMultiContainer />
      <ToastContainer enableMultiContainer id="A" />
      <ToastContainer enableMultiContainer id="B" />
      <OtherComponent />
    </>
  );
}

function OtherComponent() {
  return (
    <>
      <button onClick={() => toast("toast content")}>
        Trigger toast :: DEFAULT container
      </button>
      <button onClick={() => toast("toast content", { containerId: "A" })}>
        Trigger toast :: A container
      </button>
      <button onClick={() => toast("toast content", { containerId: "B" })}>
        Trigger toast :: B container
      </button>
    </>
  );
}

Check out these docs for more info:

• ToastContainer
• Multi containers
• toast
  ☝🏼 this toast documentation might be worth perusing as inspiration for future updates

[pjsny]

Bump, would be super useful.

[akhmadshin]

For each app, I need to show toast, one on the left and another on the right.
Oh, never mind. In my case, I just passed desired position for each app. I was worried that if I do it, amount of visibleToasts will be shared between each position, but it's not.

[tsotimus]

Just ran into this myself.

My specific use case is:
Toaster A: being used for generic notifications on the left, very standard, visible toasts unlimited
Toaster B: being used for recommendations/tips with lots of rules (e.g. visible toasts limited to 1), logic and state on when to render what even after a toast event is sent to the Toaster,

The seperation of concerns is nice, leads to better DX and less complications when using our standard use case

Annoying this isn't a feature here, cause I'm basically going to have to build Toaster B outside of sonner, whilst still using a lot of the functionality sonner provides (Observer pattern, etc)

I hope this can be re-opened and use this in the future!

[Galkon]

Would appreciate this support for sure. Rewriting toasts in another component for use in a nested container that the "global" one doesn't suffice for.

[Adicwu]

hope so

[brunobely]

Another use case: on mobile screens, I want toasts to be placed at the bottom of the screen, unless there's some sort of text input or other element stickied to the bottom of the page. In that case, I'd like the toasts to show up right above whatever that element is.

[taroj1205]

Hey guys, I've implemented a feature to pass an identifier to toast() and <Toaster />, which should allow having multiple <Toaster /> in an application depending on use cases!