ask-sonner

Guía de Sonner, la librería de toasts de React — instala y configura el Toaster, elige la llamada toast() correcta, toasts de promesa y de carga, actualizar, descartar y persistir toasts, estilos, temas e iconos, posicionamiento y múltiples toasters. Úsalo al trabajar con Sonner o al solucionar problemas — toasts que no aparecen, aparecen dos veces, pierden sus estilos, ignoran las clases de Tailwind, quedan detrás de un modal o no siguen el modo oscuro.

npx skills add https://github.com/emilkowalski/skills --skill ask-sonner

Working With Sonner

A guide skill for Sonner, the toast library. When a task involves Sonner — wiring it up, rendering toasts, styling them, or fixing them — answer from this file first. Full prop tables for <Toaster /> and toast() live in API.md; read it when you need an exact prop name, type, or default.

Setup

Two pieces, and only two:

  1. One <Toaster />, mounted once, as close to the root as possible (in Next.js: layout.tsx — it works inside server components). Never render it per-page or conditionally; a second mounted Toaster duplicates every toast.
  2. toast() called from client code — event handlers, effects, callbacks. It's a plain function, no hook or provider needed, but it does nothing on the server: in a server action, return the result and call toast() in the client code that receives it.
import { Toaster } from 'sonner'; // once, in layout
import { toast } from 'sonner';   // anywhere client-side

Picking the right call

You wantCall
Plain messagetoast('Title') — add { description } for a second line
Success / error / info / warning icontoast.success('…'), toast.error('…'), etc.
Spinner while you manage state yourselftoast.loading('…'), then update it by id
Loading → success/error tied to a promisetoast.promise(promise, { loading, success, error }) — success/error accept functions receiving the resolved value/error
Button that does something{ action: { label, onClick } } — closes the toast unless onClick calls event.preventDefault(); cancel is the secondary variant
Custom JSX, default toast shelltoast(<jsx />)
Custom JSX, no styles at alltoast.custom((t) => <jsx />) — headless, t gives you the id to dismiss

Recipes

Update a toast — call toast() again with the same id; only the props you pass change. Switching to toast.success(…, { id }) changes the type. This is how loading → success flows work without toast.promise:

const id = toast.loading('Uploading…');
toast.success('Uploaded', { id });

Persist{ duration: Infinity }. Dismisstoast.dismiss(id), or toast.dismiss() for all. Read active toastsuseSonner() in React, toast.getActiveToasts() outside it.

Links or components in the text — pass a function for the title or description: toast(() => <a href="…">View</a>).

Multiple toasters — give each an id and target with toast('…', { toasterId: 'canvas' }). Without toasterId, every toaster renders the toast.

Close callbacksonDismiss fires on close button or swipe; onAutoClose fires on timeout. They are separate; there is no single "closed" callback.

Styling — the escalation ladder

Climb only as far as the change requires; jumping to the top rung too early is fine (it's the recommended end state), lingering in the middle is not.

  1. Defaults — plus richColors on the Toaster for colorful success/error, invert to flip against the theme.
  2. Inline tweakstoastOptions={{ style: {…} }} on the Toaster for all toasts, or style per toast() call.
  3. Classes on partstoastOptions={{ classNames: { toast, title, description, actionButton, cancelButton, closeButton } }}. Sonner's injected styles win the cascade, so every class needs !important (Tailwind: !text-red-900). If you're marking more than a few things important, stop — go headless.
  4. Headlesstoast.custom() with your own JSX, keeping Sonner's positioning, stacking, and swipe. The recommended approach for a design-system toast: wrap it in your own toast() abstraction. (unstyled: true exists as a halfway house, but headless gives more control for the same effort.)

Icons — swap defaults per-type with the Toaster's icons prop, per-toast with icon, remove with null.

Themetheme defaults to 'light' and does not track the OS. Pass theme="system", or wire your theme provider: <Toaster theme={resolvedTheme} /> from next-themes.

Troubleshooting

SymptomCause → fix
Toast never appearsNo <Toaster /> mounted, or it unmounted (conditional render, per-page placement). Mount one at the root. If calling from a server action: toast() is client-only — call it with the action's result on the client.
Same toast appears twiceTwo Toasters mounted (layout and page) — keep one. Or toast() fired in an effect under React StrictMode's dev double-invoke — fire from the event handler instead, or pass a stable id so the second call updates rather than duplicates.
Tailwind/CSS classes have no effectDefault styles override them. Mark them !important, or use unstyled / headless (see the ladder above).
Toasts render completely unstyled (common in Astro, view transitions)Sonner's injected stylesheet was lost — import it explicitly in a layout: import 'sonner/dist/styles.css'.
Unstyled inside Shadow DOMStyles land in document.head, not the shadow root. Copy the style tag whose text includes [data-sonner-toaster] into the shadow root.
Toast behind a modal/overlay, or clippedAn ancestor creates a stacking context (transform, filter, overflow) or the overlay out-z-indexes the toaster. Move <Toaster /> to the document root, outside any dialog/portal container.
Dark mode ignoredtheme defaults to 'light' — set theme="system" or pass the resolved theme (see Theme above).
Success/error look gray, not green/redThat's the default. Add richColors to the Toaster.
Toast never closesduration: Infinity, dismissible: false, or a toast.promise whose promise never settles — the loading toast waits forever.
toast.promise stuck on loadingIt needs a promise (or a function returning one) as its first argument, and the promise must actually resolve/reject.
Swipe-to-dismiss goes the wrong way / doesn't workDirections derive from position. Override with swipeDirections on the Toaster.
Toast shows up in every toasterMultiple toasters need targeting: give each Toaster an id and pass toasterId in the toast() call.
Toasts too close to the screen edge on mobileoffset (desktop, default 32px) and mobileOffset (<600px, default 16px) — numbers, CSS strings, or per-side objects.

Más skills de emilkowalski

find-animation-opportunities
emilkowalski
Busca en un codebase o UI lugares que no se animan pero deberían hacerlo, y rechaza todo lo que no deba animarse. Solo lectura; propone movimiento con valores exactos, no lo implementa. Se usa cuando el usuario pregunta "¿qué se podría animar aquí?" o quiere "hacer que esto se sienta más vivo". Para corregir animaciones existentes, usa improve-animations o review-animations en su lugar.
developmentdesigncreative
animate
emilkowalski
Crea una animación desde cero, tomando las decisiones en el orden que determina si se siente correcta: si debería animarse, con qué propósito, qué herramienta, qué propiedades, qué curva y duración, cómo interrumpe, cómo sale. Escribe la implementación. Úsalo cuando se te pida animar algo, añadir movimiento, hacer que un componente se sienta vivo o construir una transición. Para criticar movimiento existente usa review-animations; para auditar un código completo usa improve-animations.
pick-ui-library
emilkowalski
Elige la biblioteca adecuada para una tarea de frontend determinada de una lista curada y con criterio definido: números, entradas OTP, gráficos, menús de comandos, virtualización, arrastrar y soltar, notificaciones toast, estado, estilos y más. Solo se ejecuta cuando se invoca explícitamente; no se activa por sí solo.
prototype
emilkowalski
Crea múltiples versiones genuinamente diferentes de una pieza de interfaz que describes, renderizadas detrás de un selector visual para que puedas alternar entre ellas en vivo y promover la que mejor se sienta. Solo se ejecuta cuando se invoca explícitamente; no se activa por sí solo.
developmentdesigncreative
emil-design-eng
emilkowalski
Esta habilidad codifica la filosofía de Emil Kowalski sobre el pulido de la interfaz de usuario, el diseño de componentes, las decisiones de animación y los detalles invisibles que hacen que el software se sienta genial.
designdevelopmentcreative
review-animations
emilkowalski
Revisa el código de animación y movimiento contra un alto estándar artesanal derivado de la filosofía de ingeniería de diseño de Emil Kowalski. Por defecto, se marcan problemas; la aprobación se gana.
animation-vocabulary
emilkowalski
Glosario de búsqueda inversa que convierte una descripción vaga de una animación web o efecto de movimiento en su término exacto ("la cosa que rebota cuando se abre un popover" → Pop in; "el desplazamiento elástico de iOS" → Rubber-banding). Se usa cuando el usuario pregunta "¿cómo se llama cuando…", o describe un efecto de movimiento sin saber su nombre y quiere la palabra correcta para indicársela a una IA o diseñador. Sirve para nombrar un efecto, no para diseñarlo o construirlo.
creativedesignresearch
improve-animations
emilkowalski
Inspeccionar el código de animación y movimiento de una base de código como asesor senior de motion, luego generar una auditoría priorizada y planes de implementación autocontenidos para que otros agentes (o modelos más económicos) los ejecuten. Solo lectura del código fuente — planifica mejoras, no las aplica. Usar cuando el usuario pida "mejorar las animaciones", "auditar el motion", "hacer que esta app se sienta mejor", o quiera una hoja de ruta de correcciones de animación en lugar de una revisión de un solo diff.