Laravel Toast Laravel Package

Product Decisions This Supports

• Unified UX for notifications: Standardize toast notifications across frontend frameworks (Vue, React, Livewire, Svelte) and backend (Laravel) to reduce fragmentation and improve developer experience—now with a shared settings UI that mirrors this parity across all supported stacks.
• Non-developer ownership of notification UX: v3.1.0 adds an authorized, browser-based settings page with live preview, letting design/product/admin users tune colors (per-part, light/dark), position, animations, and behavior without deploys or developer intervention. This directly reduces the "dev bottleneck" for micro-UX changes (e.g., brand refresh, campaign-specific styling, per-tenant themes).
• Roadmap for frontend parity: Accelerate feature rollouts (dark mode, RTL, branded theming) without rebuilding UI components; colors can be set via UI or the new colors config key for CI-driven workflows.
• Build vs. buy: Avoid reinventing toast logic and the admin tooling to configure it—an expensive combination most teams underestimate. The v3.1.0 settings page alone is typically a multi-week build if done with authorization, validation, multi-framework preview, and light/dark support.
• Per-tenant / agency differentiation: Saved settings live in an opt-in toast_settings table and merge over config; enables multi-brand deployments where each tenant's notifications reflect their palette—valuable for white-label products and agency work.
• Use cases:
  • Success/error messages post-form submission, now stylable per environment/brand.
  • Real-time alerts (Livewire updates, WebSocket events) with tunable behavior.
  • Admin dashboards where non-engineering users can iterate on feedback UX.
  • Multi-tenant/multi-brand apps needing localized, branded, dark-mode/RTL notifications.
  • Design-system stewards who want to codify a toast spec without code review loops.

When to Consider This Package

• Adopt if:

  • Your Laravel app uses multiple frontend frameworks (Vue, React, Livewire, Svelte) and needs consistent toast styling/behavior.
  • You want operational levers for non-developers (design, product, success) to tune notification UX—v3.1.0's gated settings UI enables this safely.
  • You prioritize developer velocity (56 animations + 19 props, now UI-editable) over custom UI work.
  • Your team lacks frontend expertise but needs polished, brand-configurable UIs (Tailwind/Bootstrap support).
  • You require dark mode/RTL without additional CSS overhead.
  • You operate multi-brand or multi-tenant apps where per-deployment color/behavior overrides are valuable.
  • Low-risk adoption is critical (MIT license, no breaking changes from v3.0.x, settings fully opt-in).

• Look elsewhere if:

  • You're all-in on one framework (e.g., pure React) and prefer framework-native solutions (e.g., react-toastify) with their own config UIs.
  • Your design system strictly enforces custom toast styles incompatible with Tailwind/Bootstrap.
  • You need enterprise-grade support (package has low stars/dependents; vet maintenance).
  • Your app is static (no Laravel backend) or uses non-supported frameworks.
  • You cannot accept new infra surface: v3.1.0's settings page—when enabled—adds a migration, routes, a gate, and a settings table. Teams with strict ops/DB change controls should evaluate the opt-in cost.
  • You need localized settings UI out of the box in a non-English admin experience (v3.1.0 strings ship English-only).
  • You're unwilling to rebuild frontend assets when adopting the UI feature (color payload change requires npm run build if you vendor components).

How to Pitch It (Stakeholders)

For Executives: "This package delivers consistent, polished toast notifications across all our frontend frameworks with a self-service settings page that lets design and operations teams tune colors, animations, and behavior—with live preview—without engineering cycles or deploys. It cuts dev time for common feedback loops (form submissions, alerts) while supporting dark mode, RTL, per-brand theming, and now non-technical iteration on UX. The v3.1.0 release is fully opt-in and off by default with a closed-by-default gate, so we can adopt incrementally. MIT license, no breaking changes, and Laravel-native integration keep risk low while giving us a notification system we can evolve as the product and brand do."

For Engineering: *"Laravel-Toast v3.1.0 keeps the v3.0.x public API, config, views, and payloads unchanged—upgrades require no mandatory steps—but adds an optional notification settings subsystem that's off by default (no table, no routes, no CSS changes until enabled). Highlights:

• Settings UI for every frontend: Blade (@toastSettings), Livewire <livewire:toast-settings />, plus Vue/React/Svelte components. Tailwind v4 / Bootstrap 5 / Bootstrap 4 views for Blade & Livewire.
• Colors per part per mode: background, text, border, icon, progress bar, track—independently for light/dark; Default defers to the CSS framework; also settable via the colors config key for CI/declarative workflows.
• Saved settings override config: opt-in toast_settings table merges over config/toast.php and .env; anything unsaved falls back to config—clean layering.
• Security posture: undefined gate denies everyone; middleware runs before the gate; form request rejects unknown keys and invalid values with 422; hex validated (#rgb/#rrggbb) before storage and CSS emission.
• Install/update ergonomics: toast:install/toast:update gain --settings, --settings-page, --settings-layout=, --settings-section=, --settings-middleware=, --settings-gate=. Validation before writes; commands never run migrations or define the gate.
• Quality signals: 413 PHP tests (774 assertions), 78 frontend tests, 11 Chromium E2E tests; CI across PHP 8.2–8.5, Laravel 10–13, Livewire 3/4; Codacy A with zero issues (down from ~1,200).
• Operational notes to plan for: settings strings are English-only today; the standalone settings page (no layout configured) loads CDN CSS—always set a layout for production; if you've published toast-views, merge the new data-toast-type / data-toast-part attributes or configured colors won't reach your markup; if you vendor Vue/React/Svelte containers, rebuild assets and import applyToastColors from toast-options.js (or use toast.colors_css). Tradeoff: Adds an optional operational surface (migration + routes + gate) when enabled—gated, validated, and reversible (.env toggle or migrate:rollback). Ideal for MVP acceleration, cross-team consistency, and giving non-engineers safe control over notification UX."*