标签：#livewire

Wiremodal is a framework-agnostic modal package for Laravel, which allows to handle modals, so you don't have co configure them in all your projects. It ships a few Livewire-side helpers that make exactly this pleasant. This post is the Livewire integration end to end: opening and closing from PHP, delivering a payload on open, the one trap to avoid, and the optional form panel for when a modal happens to be a form. How to install Pull the package in and get the assets onto the page. composer require edulazaro/wiremodal php artisan vendor:publish --tag = wiremodal-assets The service provider auto-registers and there is no config file. Point your layout at the published files: <link rel="stylesheet" href="{{ asset('vendor/wiremodal/css/wiremodal.css') }}"> <script src="{{ asset('vendor/wiremodal/js/wiremodal.js') }}" defer></script> If you bundle with Vite, skip the publish and import straight from the vendor directory instead, so a package update flows through without re-publishing anything: /* resources/css/app.css */ @import "../../vendor/edulazaro/wiremodal/resources/css/wiremodal.css" ; // resources/js/app.js import ' ../../vendor/edulazaro/wiremodal/resources/js/wiremodal.js ' ; Opening and closing from Livewire Define the modal once with the <x-wiremodal> component, give it a name , and fill the body and footer slots. Here is a delete confirmation: <x-wiremodal name="confirm-delete" title="Delete record?" size="sm"> <x-slot:body> <p>This action cannot be undone.</p> </x-slot:body> <x-slot:footer> <button type="button" data-wm-dismiss>Cancel</button> <button type="button" wire:click="destroy">Delete</button> </x-slot:footer> </x-wiremodal> The Cancel button carries data-wm-dismiss , and any element with that attribute closes the modal it sits in, so you never write a cancel handler. To open and close from the component itself, use the macros the package registers on every Livewire component: public function confirmDelete (): void { $this -> openModal ( 'confirm

Bundling an admin UI inside a Laravel package is a different game from building one in an app. The app's conveniences — a compiled Vite manifest, a registered layout, your own Livewire components — aren't there. Today, getting the bundled admin UI in laravel-config-webhook to actually render meant walking through four separate 500s. Each one is a small, sharp lesson about the boundary between a package and its host app. 1. A Livewire 4 component name can't contain :: I registered the component with a namespaced-looking name and got a ComponentNotFoundException at runtime. The cause is subtle: under Livewire 4, a name containing :: triggers namespace resolution that ignores singly-registered components. So a "nice looking" name silently routes to a lookup that will never find it. The fix is to register a plain, dotted name: // ❌ looks tidy, but the "::" sends Livewire down a namespace path Livewire :: component ( 'config-webhook::webhooks' , Webhooks :: class ); // ✅ a flat dotted name resolves to the singly-registered component Livewire :: component ( 'config-webhook.webhooks' , Webhooks :: class ); Lesson: in a package, treat the component name as an identifier with framework-reserved characters — :: is not yours to use. 2. Flux ships Heroicons, not Pro/Lucide names The free tier of Flux ships Heroicons . Reach for a Pro-only or Lucide-style name and it throws at runtime. I'd used webhook , ellipsis , and list ; the free equivalents are bolt , ellipsis-horizontal , and queue-list . This is the same trap that bit my SSO package — which is exactly why I now guard it with a static test that reads the Blade and checks every icon against Flux's actual stub files. (Separate post on that.) If you ship a package UI with Flux, assume free-tier icons only unless you require Pro. 3. Don't @vite host assets that don't exist The bundled fallback layout @vite -d the host app's assets. In a fresh consumer (or the package's own workbench) there's no compiled manifest, so you get a