Mental Model

@ilokesto/toast is easiest to understand if you keep three layers in your head:

• the toast facade
• the provider-scoped runtime
• the overlay-backed presence lifecycle

Runtime registry by toasterId

There is no implicit global singleton. Each Toaster registers one runtime by toasterId.

When you call toast.success(), the facade resolves the runtime from the registry first.

Facade / runtime split

The imported toast object does not own state. It only routes commands.

The runtime owns:

• item state
• timers
• dismiss/remove behavior
• visible filtering
• pause/resume behavior

Store plus overlay presence split

Each runtime uses:

• a toast store for toast data and timers
• an overlay store for presence lifecycle only

This is why toast rendering feels higher-level than overlay even though overlay still participates under the hood.

Options merge order

The effective options are merged in this order:

1. global toastOptions
2. per-type toastOptions.success/error/loading/blank/custom
3. per-toast call options

Dismiss vs remove

• dismiss() is soft close + delayed removal
• remove() is immediate deletion

That distinction matters for animation and lifecycle timing.

If you want the exact public surface next, read API Reference. If you want rendering details, go to Toaster.