4. Sonner in practice — fast start and advanced tweaks

Installation & basic setup

Installing Sonner is intentionally unceremonious — you add the package, add a toaster component near your app root, and call toast(…) whenever you need to notify. No magic wrappers, no huge providers. This minimal friction is why developers choose small, focused libraries for toast notifications.

Typical install commands are npm & yarn; after that, render the <Toaster /> once (usually in App.tsx or index.tsx). You get sensible defaults: placement, animations and auto-dismiss, which let you ship notifications without fiddling.

Remember accessibility: even tiny notification UIs should expose roles and polite live regions where appropriate. Sonner and similar libs often include ARIA follow-ups or provide hooks to facilitate accessible announcements; check docs and add aria-live attributes if you need strict screen reader behavior.

// install
npm i sonner
// basic usage (React)
import { Toaster, toast } from 'sonner'

function App(){
  return (
    <>
      
       toast('Saved')}>Notify
    
  )
}

Practical example: toast messages & promise handling

Simple messages are the bread-and-butter: toast(’message’) or toast.success(’done’). But the real productivity hack is promise toasts (a single notification that reflects the lifecycle of an async task). Instead of firing separate toasts for loading and success, you show one toast that morphs when the promise settles.

Promise-based toasts are excellent when you want to avoid notification spam. They keep a clean timeline: loading → success/error. Most modern toast libs expose a promise helper or allow you to pass the promise to a toast function so it updates itself.

Use cases: file uploads, API saves, payments, or long-running background jobs. They keep the UI tidy and reduce mental load — because users prefer one evolving message to five separate popups.

// pseudo-code for a promise toast
const p = apiCall()
toast.promise(p, {
  loading: 'Saving...',
  success: 'Saved!',
  error: 'Save failed'
})

Hooks, updates and customization

If you’re building a component library or want tighter control, Sonner-like libraries expose hooks (e.g., useToast) to programmatically create toast instances, update them, or dismiss by id. Hooks are handy for encapsulating notification behavior inside domain-specific utilities.

Customization goes beyond colors. You can replace the default renderer to include custom icons, link actions (undo), or inject components like progress bars. Styling is usually done via CSS-in-JS or class overrides, so Sonner plays well with Tailwind, Emotion, or plain CSS modules.

Two practical tips: 1) scope style overrides to the Toaster container to avoid global leakage; 2) provide consistent durations for critical vs. informational toasts — e.g., 8s for errors, 3s for info.

Best practices: performance, SSR and accessibility

Keep toasts lightweight. Avoid rendering heavy subtrees inside notifications. Lazy content or links that trigger additional code can inflate bundle sizes and reduce perceived performance. For global notifications, prefer serialized messages or short payload references.

Server-side rendering: render a placeholder or avoid toasting during SSR. Trigger toasts on client hydration or in effect hooks. Some tutorial posts show patterns: store events server-side and dispatch toasts only after hydration.

Accessibility checklist: aria-live regions, focus management for interactive toasts (undo buttons), keyboard dismissibility, and sufficient contrast for toast text and icons. These are often overlooked in quick tutorials but essential in production apps.

Advanced integration patterns

Integrate Sonner with global state (Redux / Zustand) by creating a thin adapter: when a state slice indicates a notification, dispatch toast calls and clear the flag. This keeps presentation concerns out of the business logic while allowing centralized notification control.

For multi-channel notifications (websocket / server-sent events), funnel incoming events into the toast API surface and consider deduplication rules to avoid flooding the user when multiple events occur in a short span.

Finally, for teams shipping design systems: include a wrapper component that standardizes toast variants (info/success/error), iconography and durations. This reduces onboarding friction for other developers.