ask-sonner

Guide de Sonner, la bibliothèque de toasts React — installer et configurer le Toaster, choisir le bon appel toast(), les toasts de promesse et de chargement, la mise à jour, la fermeture et la persistance des toasts, le style, les thèmes et les icônes, le positionnement et les toasters multiples. À utiliser lorsque vous travaillez avec Sonner ou pour résoudre ses problèmes — toasts qui n'apparaissent pas, apparaissent deux fois, perdent leur style, ignorent les classes Tailwind, se trouvent derrière une modale ou ne suivent pas le mode sombre.

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.

Plus de skills de emilkowalski

find-animation-opportunities
emilkowalski
Recherchez dans une base de code ou une interface utilisateur les endroits qui ne s'animent pas mais qui le devraient, et rejetez tout ce qui ne devrait pas. Lecture seule ; il propose des animations avec des valeurs exactes, il ne les implémente pas. À utiliser lorsque l'utilisateur demande « qu'est-ce qui pourrait être animé ici ? » ou souhaite « rendre cela plus vivant ». Pour corriger des animations existantes, utilisez plutôt improve-animations ou review-animations.
developmentdesigncreative
animate
emilkowalski
Construire une animation de zéro, en prenant les décisions dans l'ordre qui détermine si elle semble juste — faut-il l'animer, dans quel but, quel outil, quelles propriétés, quelle courbe et durée, comment elle interrompt, comment elle sort. Écrit l'implémentation. À utiliser lorsqu'on demande d'animer quelque chose, d'ajouter du mouvement, de rendre un composant vivant, ou de construire une transition. Pour critiquer une animation existante, utiliser review-animations ; pour auditer une base de code entière, utiliser improve-animations.
pick-ui-library
emilkowalski
Choisissez la bonne bibliothèque pour une tâche frontend donnée à partir d'une liste organisée et assumée — nombres, champs OTP, graphiques, menus de commandes, virtualisation, glisser-déposer, toasts, état, styles, et plus encore. Ne s'exécute que lorsqu'il est explicitement invoqué ; il ne se déclenche pas de lui-même.
prototype
emilkowalski
Construisez plusieurs versions réellement différentes d’un élément d’interface que vous décrivez, rendues derrière un sélecteur visuel afin de pouvoir les parcourir en direct et promouvoir celle qui convient le mieux. Ne s’exécute que lorsqu’il est explicitement invoqué ; il ne se déclenche pas de lui-même.
developmentdesigncreative
emil-design-eng
emilkowalski
Cette compétence encode la philosophie d'Emil Kowalski sur le polissage de l'interface utilisateur, la conception de composants, les décisions d'animation et les détails invisibles qui rendent un logiciel agréable à utiliser.
designdevelopmentcreative
review-animations
emilkowalski
Examine le code d'animation et de mouvement par rapport à un haut niveau d'exigence artisanale dérivé de la philosophie d'ingénierie de conception d'Emil Kowalski. Par défaut, signaler ; l'approbation se mérite.
animation-vocabulary
emilkowalski
Glossaire de recherche inversée qui transforme une description vague d’une animation web ou d’un effet de mouvement en son terme exact (« le truc rebondissant quand une popover s’ouvre » → Pop in ; « le défilement élastique d’iOS » → Rubber-banding). À utiliser lorsque l’utilisateur demande « comment ça s’appelle quand… », ou décrit un effet de mouvement sans connaître son nom et souhaite le mot juste pour interpeller une IA ou un designer. Pour nommer un effet, non pour le concevoir ou le construire.
creativedesignresearch
improve-animations
emilkowalski
Examiner le code d'animation et de mouvement d'une base de code en tant que conseiller senior en motion, puis produire un audit priorisé et des plans d'implémentation autonomes pour que d'autres agents (ou des modèles moins coûteux) les exécutent. Lecture seule du code source — il planifie des améliorations, il ne les applique pas. À utiliser lorsque l'utilisateur demande « améliorer les animations », « auditer le mouvement », « rendre cette application plus agréable », ou souhaite une feuille de route de corrections d'animations plutôt qu'une révision d'une seule modification.