About Myself

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:

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:

    
        
This action cannot be undone.

    
    
        Cancel
        Delete
    

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-delete');
}

public function destroy(): void
{
    // delete the record...
    $this->closeModal('confirm-delete');
}

That is the whole open and close cycle from the server, and there is nothing to import: openModal and closeModal are macros wiremodal adds for you.

Handing the modal a payload

A confirmation needs no data, but most modals do: the row you clicked. openModal() takes a second argument, and Wiremodal delivers it to the modal through a wiremodal:opened event whose detail is { name, data }, fired on both the modal element and window. You read it with a one-line Alpine handler.

public function view(int $id): void
{
    $task = Task::findOrFail($id);

    $this->openModal('task-detail', [
        'id'    => $task->id,
        'title' => $task->title,
    ]);
}

    x-data="{ task: {} }"
    @wiremodal:opened.window="if ($event.detail.name === 'task-detail') task = $event.detail.data || {}">
    
        

    
    
        Close
    

The if ($event.detail.name === ...) guard matters because the event fires on window for every modal, so each one only reacts to its own payload. The panel fills with the right row the instant it opens.

The positional-dispatch trap

There is one mistake worth calling out, because it fails silently. Do not skip the macro and dispatch the browser event yourself with a positional string:

// Silently never opens the modal
$this->dispatch('open-wiremodal', 'task-detail');

Livewire wraps that positional string into an array, so the browser receives e.detail = ['task-detail']. Wiremodal’s parser accepts a bare string or an object with a name key, never an array, so the modal just never opens and no error is thrown. The openModal() and closeModal() macros exist precisely to avoid this, since they dispatch with named arguments under the hood. If you ever dispatch by hand, use the named form:

$this->dispatch('open-wiremodal', name: 'task-detail', data: ['id' => 42]);

When the modal is a form

Everything above works for any modal. When the modal happens to be a form and you want native submission, the Enter key and a real submit button, add as="form". It renders the panel as a <form> instead of a <div>, so wire:submit fires on submit and the autofocus attribute is honored.

    as="form" wire:submit="save"
    x-data
    @wiremodal:opened.window="
        if ($event.detail.name === 'edit-task') {
            $wire.set('editingId', $event.detail.data.id);
            $wire.set('title', $event.detail.data.title);
        }
    ">
    
        
            Title
            
        
    
    
        Cancel
        Save
    

public ?int $editingId = null;
public string $title = '';

public function save(): void
{
    Task::findOrFail($this->editingId)->update(['title' => $this->title]);
    $this->closeModal('edit-task');
}

You open it exactly as before with openModal('edit-task', [...]); the only difference is as="form" turning the panel into a real form so Enter and the submit button drive wire:submit. Without it you would hang a wire:click on the Save button instead. That is the point: the form is one prop, not the price of entry.

Sizes and persistent modals

Two props round it out. size takes one of eleven named widths and defaults to 2xl (42rem), running from xs (20rem) to 7xl (80rem); a value outside the catalog throws an InvalidArgumentException at render, so a typo fails loudly instead of producing a wrong-sized box.

Use fullscreen to fill the viewport. And persistent makes a modal ignore overlay clicks and the ESC key, so a wizard step or a you must choose prompt only closes through an explicit data-wm-dismiss button or a programmatic closeModal().

👉 Package on Packagist: https://packagist.org/packages/edulazaro/wiremodal
👉 Source on GitHub: https://github.com/edulazaro/wiremodal

If you’re still shipping a CSS-in-JS runtime just to color a button, it’s worth asking why.

traceless-style compiles every style at build time — zero runtime, zero CSS-in-JS engine on the page. What you ship is clean, deduped atomic CSS.

A quick look

import { tl } from "traceless-style";

const $ = tl.create({
  card: {
    padding: "1.5rem",
    background: "#ffffff",
    color: "#0f172a",
    borderRadius: "12px",

    _hover: { transform: "translateY(-2px)" },
    _dark: { background: "#13131a" },
  },
});

...
;

This compiles down to plain atomic classes:

.tlm92pvu { padding: 1.5rem }
.tla7dffa { background: #ffffff }
.tlb1c4lk { color: #0f172a }
.tlc883bz { border-radius: 12px }
.tld5e2f1:hover { transform: translateY(-2px) }
.dark .tla7dffa { background: #13131a }

No styled-components wrapper. No Babel plugin. No CSS-in-JS engine running in the browser.

What makes it different

Zero runtime, by construction

Every tl.create call is statically transformed at build time into a class-string literal. The only runtime helper left is ~2 KB, and it exists solely for SSR and non-bundled tests.

WCAG built into the build

This is the part that stands out. Every style block is checked against WCAG 2.1 §1.4.3 (AA 4.5:1), §1.4.6 (AAA 7:1), §1.4.11 (UI 3:1), and §2.4.13 (focus 3:1) — before your CSS is written to disk.

For about a day I believed I had roughly 150 broken tests. I was wrong — not one of them was broken. Then I was wrong about the cause. Twice.

Here’s the walk from “our test suite is rotting” to “one stray line in my shell was winning a fight I didn’t know it was in.”

The symptom

I ran the suite and about half of it was red. Every failure was the same shape: 403 org-access-denied. Tenant-scoped tests, denied across the board.

It looked exactly like accumulated test debt — the kind of thing you file, sigh at, and schedule for “later.” So that’s what I did. I opened an issue: ~150 failing tests, org access denied.

Correction #1: the tests were fine, my machine wasn’t

Before scheduling the cleanup, I ran the suite in a clean environment — a fresh shell with none of my profile loaded.

All green.

Not “fewer failures.” Zero. The tests were fine. The failures were a property of my environment, not the code. Which is a worse feeling than a broken test, honestly, because it means the call is coming from inside the house.

The mechanism turned out to be a PHPUnit detail I’d never had to think about: env vars you set in the config do not override an env var that’s already set in your shell — not unless you mark them force="true". My shell profile exported a variable that the test config also set, and by default, the shell won. So my tests were quietly running against the wrong context, and everything tenant-scoped got denied.

Correction #2: I blamed the scary variable, not the guilty one

Here’s the part I’m least proud of and find most useful.

My first theory for which variable was a JWT signing secret. It’s the dangerous-sounding one; of course a bad secret breaks auth. I wrote it up that way.

It was wrong, and the code says why. A signing secret is symmetric: if signing and verifying both read the same (wrong) value, the tokens are still internally valid. A polluted secret doesn’t produce 403 org-access-denied — it produces valid tokens for a wrong-but-consistent world. It couldn’t be the cause.

The actual culprit was boring: a tenant-slug variable. My shell had it set to one thing; the tests minted tokens for another. So the request would resolve one tenant from the env, carry a token for a different tenant, and the access check — correctly — denied it. Every tenant-scoped test, 403.

I’d spent my first guess on the variable that sounded like a security problem, when a plain identifier was doing all the damage.

The fix was one attribute

force="true" on the env entries, so the test configuration wins over whatever the shell happens to export. That’s it. The suite is now hermetic: it runs the same on my machine, on a colleague’s, and in CI, regardless of anyone’s shell profile.

I proved it the honest way — by injecting the bad variable on purpose. With the injection and no force, the suite collapses (about 150 failures and a pile of errors). With force, the same injection does nothing; everything stays green. The fix is verified against the attack, not against my memory.

What I can’t tell you

I can’t tell you the exact line that was in my shell profile that day. I don’t have it pinned down, and I’m not going to invent it to make the story cleaner. What I have is a reproduction — inject the variable, watch it break — and that’s what the fix is proven against.

The count is fuzzy too. It was around 150 failures out of somewhere near 290 tests, and both numbers drifted day to day as the suite changed. “156 out of 291” would look precise and be a small lie. Half the suite red, zero tests actually broken is the true and useful shape of it.

Two takeaways

Make your tests hermetic. Test configuration should beat the machine it runs on, unconditionally — force, or the equivalent in your stack. A suite whose result depends on the developer’s shell isn’t testing your code; it’s testing your dotfiles.

When you’re debugging, suspect the boring variable. I lost real time pointing at a secret because it sounded dangerous, while a plain tenant id sat there quietly denying everything. The scary-looking cause is a great way to feel productive and stay wrong.

What’s the worst “it’s the tests” you’ve had that turned out to be your own environment?

── Hideyuki Mori (Ayane International) 🔗 hideyuki-mori.com

HideyukiMORIFollow

Building API-first PHP tools for self-hosted business workflows. Creator of NENE2 and the NeNe OSS series.