ask-sonner

作者: emilkowalski

Sonner(React toast 函式庫)使用指南——安裝並接上 Toaster、選用正確的 toast() 呼叫、promise 與 loading toast、更新、關閉及持久化 toast、樣式、主題與圖示、定位與多個 toaster。適用於使用 Sonner 或排解其問題時——例如 toast 未出現、出現兩次、失去樣式、忽略 Tailwind 類別、位於 modal 後方,或未跟隨深色模式。

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.

來自 emilkowalski 的更多技能

find-animation-opportunities
emilkowalski
搜尋程式碼庫或 UI 中應該有動畫但沒有的地方,並排除所有不應該有動畫的部分。唯讀;它會提出具有精確數值的動畫建議,但不會實際實作。當使用者詢問「這裡可以加入什麼動畫?」或想要「讓這個感覺更有生命力」時使用。若要修復現有的動畫,請改用 improve-animations 或 review-animations。
developmentdesigncreative
animate
emilkowalski
從零開始建立動畫,依序做出決定,以判斷整體是否自然流暢——是否該有動畫、目的為何、選用哪種工具、哪些屬性、哪條曲線與時長、如何打斷、如何結束。並撰寫實作內容。當被要求為某個東西加上動畫、增添動態感、讓元件更有生命力,或建立轉場效果時使用。若要評論現有動態效果,請使用 review-animations;若要審查整個程式碼庫,請使用 improve-animations。
pick-ui-library
emilkowalski
從精心策劃且具主觀推薦的清單中,為指定的前端任務挑選合適的函式庫——涵蓋數字、OTP輸入、圖表、指令選單、虛擬化、拖放、提示訊息、狀態管理、樣式等。僅在明確呼叫時執行;不會自行觸發。
prototype
emilkowalski
為你描述的UI元件建立多個真正不同的版本,並在視覺選取器後方渲染,讓你能夠即時切換瀏覽,選出最合適的那一個。僅在明確呼叫時執行;不會自行觸發。
developmentdesigncreative
emil-design-eng
emilkowalski
此技能編碼了 Emil Kowalski 關於 UI 打磨、元件設計、動畫決策,以及那些讓軟體體驗出色的隱形細節的設計哲學。
designdevelopmentcreative
review-animations
emilkowalski
根據 Emil Kowalski 的設計工程哲學所建立的高標準,審查動畫與動態程式碼。預設為標記問題;需主動爭取才能獲得核准。
animation-vocabulary
emilkowalski
反向查詢詞彙表,將模糊描述的網頁動畫或動態效果轉換為精確術語(例如:「彈出視窗開啟時的彈跳效果」→ Pop in;「iOS橡皮筋滾動」→ Rubber-banding)。適用於使用者詢問「那個叫什麼…」或描述某個動態效果卻不知其名稱,並希望獲得正確詞彙以提示AI或設計師時使用。此功能僅用於命名效果,而非設計或實作。
creativedesignresearch
improve-animations
emilkowalski
以資深動畫顧問的身份,審查程式碼庫中的動畫與動態程式碼,產出優先排序的稽核報告與可獨立執行的實作計畫,供其他代理(或較低成本模型)執行。僅對原始碼進行唯讀操作——負責規劃改進,不實際套用。適用於使用者要求「改善動畫」、「稽核動態」、「讓這個應用程式感覺更好」,或希望獲得動畫修正路線圖(而非單一差異審查)時。