Skip to content

Notification provider: pluggable notify() instead of hardcoded sonner toasts in every plugin #131

Description

@olliethedev

Context

Part of the Refine-inspired core simplification effort (#127 ✅, #128, #129, #130 ✅, #132, #133). Refine's mutations report success/failure through a pluggable notificationProvider instead of binding a toast library inside the framework.

Scope note: this issue covers the core provider only (phase 1). The sweep replacing 50+ direct sonner call sites across ~15 files in 9 plugins is tracked in #136 (phase 2).

Problem

Plugin components call toast.success(...) / toast.error(...) directly:

  • Consumers cannot route plugin notifications through their own notification system (or suppress/translate them)
  • Sonner is effectively a hard dependency of every plugin UI
  • Success/error messaging is scattered through components as try/catch + toast instead of living with mutation definitions

Proposal

A notify provider on StackProvider, with sonner as the default so behavior is unchanged out of the box:

<StackProvider
  notify={{
    success: (msg, opts) => myToast.success(msg),
    error: (msg, opts) => myToast.error(msg),
    // optional: info, warning
  }}
  ...
>

Scope (core only)

  • notify prop on StackProvider + useNotify() hook + sonner default implementation
  • Unit tests: custom provider receives notifications; default falls back to sonner
  • Docs: StackProvider reference + short "custom notifications" guide

Acceptance criteria

Plugin sweep (removing direct sonner imports) → #136.

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or request

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions