Implementation Notes

This page explains the current implementation details that matter when you need to understand how the runtime really behaves.

One runtime, several moving parts

Each Toaster creates one ToastRuntimeApi with:

• a toast store
• an overlay store
• dismiss timers
• remove timers
• a listener set
• runtime-local view config

Registry lookup

The facade never holds runtime state directly. It resolves a runtime by toasterId through the registry.

If no runtime is mounted, requireRuntime() throws.

Overlay presence mirror

When a toast is added, the runtime ensures matching presence in an overlay store using id reuse.

• add toast -> ensure overlay presence
• dismiss toast -> close overlay presence
• remove toast -> remove overlay presence

The overlay layer is used for presence lifecycle only, not for toast policy.

Timers and pause logic

• visible toasts schedule dismiss timers based on duration minus accumulated pause duration
• dismiss schedules delayed removal
• hover pause clears dismiss timers and records pause start time
• resume recomputes dismiss timing from the accumulated pause duration

Visible filtering

limit and position are runtime view filters. They do not delete raw store entries.

Promise transitions

toast.promise() creates a loading toast first, then reuses the same id for success or error.