Laravel Livewire Toasts Laravel Package

Getting Started

1. Install

composer require bastinald/laravel-livewire-toasts

Livewire is a hard dependency — make sure livewire/livewire is already installed and set up (its service provider is auto-discovered). The package is not configured via a published config file, so there is no php artisan vendor:publish step for most installations.

2. Add Bootstrap 5 to your layout

The component renders Bootstrap markup, so your layout must load Bootstrap CSS (for styling) and Bootstrap's bundle JS (for the auto-dismiss animation and the close button). Without the JS bundle, toasts will render but never hide.

<link href="https://cdn.jsdelivr.net/npm/[email protected]/dist/css/bootstrap.min.css" rel="stylesheet">
<script src="https://cdn.jsdelivr.net/npm/[email protected]/dist/js/bootstrap.bundle.min.js"></script>

3. Drop the toast component into your app layout

Put the toast Livewire component once, near the end of <body>, in resources/views/layouts/app.blade.php (or whatever your global layout is). Every page that extends that layout will then be able to receive toasts. Confirm the exact tag name by looking at the package's resources/views folder after install — it follows the namespaced convention (<livewire:laravel-livewire-toasts::toasts /> or similar) in Bastinald's other packages.

4. First use case

From any Livewire component method, dispatch a toast right before returning:

public function save()
{
    $this->validate();
    $this->post->save();

    toast('Post saved.', 'success');

    return redirect()->route('posts.index');
}

The toast() helper is what the package's service provider registers. It accepts the message plus a Bootstrap context (success, danger, warning, info, primary, etc.). Open src/ after install to verify the exact signature — the package is small and the helper is the entire API surface.

Implementation Patterns

Single toast per save action. The most common pattern is a one-liner at the end of a mutation method, immediately before the redirect or the $this->reset(). Keeping it in the component (not the view) means toasts fire consistently from Livewire actions, plain controller actions, and console commands alike.

Multiple sequential toasts. Because each toast is queued onto the component's internal state, calling toast() more than once in the same request stacks them. This is useful for "Record 3 of 5 imported" style batch feedback:

foreach ($rows as $row) {
    if (! $row->save()) {
        toast("Row {$row->id} failed.", 'danger');
    }
}
toast('Import complete.', 'success');

Error and validation feedback. Pair with Livewire validation so failures surface as a toast rather than an inline alert:

public function delete()
{
    try {
        $this->post->delete();
        toast('Deleted.', 'success');
    } catch (\Throwable $e) {
        toast('Could not delete.', 'danger');
        report($e);
    }
}

Integration with redirects and flash messaging. Because Livewire re-renders the toast component after a redirect, toast() calls made just before return redirect() still survive the round trip. This makes it a clean drop-in for the classic session()->flash('status', ...) pattern — replace the flash with a toast and delete the matching <div class="alert"> block from your layout.

Wiring into plain (non-Livewire) controllers. If the helper writes to the session as well (check src/ — some Bastinald versions do), you can call toast() from a standard Laravel controller and the toast component will pick it up on the next full page load. This lets you standardize one feedback mechanism across your Livewire and non-Livewire code.

Reusable component trait. If you emit toasts from dozens of components, wrap the helper in a small trait with helpers like $this->toastSuccess('...') / $this->toastError('...') so intent is readable and Bootstrap context strings stay out of business logic.

Gotchas and Tips

The package is tiny — read the source first. At ~16 stars and a handful of files, the fastest way to understand the API is to open vendor/bastinald/laravel-livewire-toasts/src/. Confirm: the helper name, its parameter order (message, type?), the component tag, and whether it uses wire: attributes (Livewire v2) or the #[On]/dispatch API (v3). Version mismatches here are the single biggest source of "toast never appears" issues.

Bootstrap JS is required for auto-dismiss. If toasts appear but never go away, bootstrap.bundle.js is missing or loaded before the toast DOM. Load it in <head> with defer, or just before </body> — do not load it in a @stack that renders after your app JS runs.

Stack order matters. The toast component must be inside the same Livewire root as the action that fires it (or rendered at the app layout level, above any @livewireScripts). If you place the component inside <x-slot> or a nested Blade component that doesn't render on redirect, queued toasts get lost on the redirect response.

One toast container per layout. Rendering the toast component on multiple pages in a stack (once in a partial and once in a layout) duplicates the Livewire components and can cause flicker or double-rendering as both react to the same event.

Timing is not configurable from a config file. If you want a different auto-dismiss delay, either pass an extra argument to the helper (if the version supports it) or fork/copy the view and set data-bs-delay. Because there is no publishable config, plan to override the Blade view if you need to change markup — check whether the package registers its view namespace with loadViewsFrom, then override via resources/views/vendor/... or a @push of a small script.

Testing. In a Livewire test, assert on the emitted event rather than the DOM:

Livewire::test(SavePost::class)
    ->call('save')
    ->assertDispatched('toast'); // use the event name in the package source

If the helper writes to session, use assertSessionHas(...) — but read src/ first to confirm which mechanism is in play. This is the one place where a wrong guess leads to a false-positive test.

Do not use it for validation errors you want to display inline. toast() is fire-and-forget; it is not a substitute for Livewire's $errors bag. Use @error for field-level problems and reserve toasts for action outcomes.

Extension points are limited. Without a service provider hook or config file, customization is generally (a) wrapping the helper, (b) overriding the view, or (c) forking. If toasts are central to your UX, consider this a scaffolding package rather than a UI framework — plan to own the view once the design diverges from stock Bootstrap.