It is just this: dispatch a small Alpine event from the place where the interaction happens, let another Livewire component listen to it, and make the UI feel instant before the server round-trip finishes.

That pattern has been stuck in my head ever since this moment from Caleb's talk:

The Shape Of The Problem

One component owns the action. Another component somewhere else on the page needs to react to it.

For example:

• a row action updates a negotiation state
• a summary card needs to refresh
• a badge count should move instantly

I did not want to refresh everything. I also did not want to build a big store just to move one piece of information across the page.

The Source Component

The first component handles the click, updates the visible state optimistically, and dispatches a browser event with the useful details.

 1<div
 2    x-data="{
 3        approved: @js($approved),
 4        pending: false,
 5        async approve() {
 6            if (this.pending) return
 7 
 8            this.pending = true
 9            this.approved = true
10 
11            $dispatch('negotiation-approved', {
12                negotiationId: @js($negotiation->id),
13                approved: true,
14            })
15 
16            try {
17                await $wire.approve()
18            } catch (error) {
19                this.approved = false
20 
21                $dispatch('negotiation-approved', {
22                    negotiationId: @js($negotiation->id),
23                    approved: false,
24                })
25            } finally {
26                this.pending = false
27            }
28        }
29    }"
30>
31    <button
32        type="button"
33        x-on:click="approve()"
34        x-bind:disabled="pending"
35        class="rounded-full border px-4 py-2"
36    >
37        <span x-show="!pending && !approved">Approve</span>
38        <span x-show="pending">Approving...</span>
39        <span x-show="!pending && approved">Approved</span>
40    </button>
41</div>

 1<div
 2    x-data="{
 3        approved: @js($approved),
 4        pending: false,
 5        async approve() {
 6            if (this.pending) return
 7 
 8            this.pending = true
 9            this.approved = true
10 
11            $dispatch('negotiation-approved', {
12                negotiationId: @js($negotiation->id),
13                approved: true,
14            })
15 
16            try {
17                await $wire.approve()
18            } catch (error) {
19                this.approved = false
20 
21                $dispatch('negotiation-approved', {
22                    negotiationId: @js($negotiation->id),
23                    approved: false,
24                })
25            } finally {
26                this.pending = false
27            }
28        }
29    }"
30>
31    <button
32        type="button"
33        x-on:click="approve()"
34        x-bind:disabled="pending"
35        class="rounded-full border px-4 py-2"
36    >
37        <span x-show="!pending && !approved">Approve</span>
38        <span x-show="pending">Approving...</span>
39        <span x-show="!pending && approved">Approved</span>
40    </button>
41</div>

That part matters: the user sees the state move immediately. The server still confirms the truth, but the interface does not feel late.

The Other Livewire Component

Now another component can listen for that event with Alpine and hand control back to its own $wire.

 1<div
 2    x-data="{ approvedCount: @js($this->approvedCount) }"
 3    x-on:negotiation-approved.window="
 4        approvedCount = $event.detail.approved
 5            ? approvedCount + 1
 6            : Math.max(approvedCount - 1, 0)
 7 
 8        $wire.refreshApprovedCount()
 9    "
10>
11    <p class="text-sm text-zinc-500">Approved negotiations</p>
12    <p class="text-3xl font-semibold" x-text="approvedCount"></p>
13</div>

 1<div
 2    x-data="{ approvedCount: @js($this->approvedCount) }"
 3    x-on:negotiation-approved.window="
 4        approvedCount = $event.detail.approved
 5            ? approvedCount + 1
 6            : Math.max(approvedCount - 1, 0)
 7 
 8        $wire.refreshApprovedCount()
 9    "
10>
11    <p class="text-sm text-zinc-500">Approved negotiations</p>
12    <p class="text-3xl font-semibold" x-text="approvedCount"></p>
13</div>

I like this because the boundary stays clear:

• Alpine handles the tiny front-end interaction
• the event carries only what the rest of the page needs
• the second Livewire component decides how to reconcile itself

Why The Optimistic Part Helps

Without the optimistic step, the interaction waits on the network. That usually means:

• the button feels heavier than it should
• the badge updates too late
• the UI looks unsure even when the action is simple

With the optimistic step, the page feels more direct. If the backend disagrees, you still have a rollback path. But most of the time, the interface gets to feel correct at the exact moment the user clicked.

Why I Reach For This

This pattern is small, but it scales well.

It works when:

• you want components to stay separate
• you only need to share one small state change
• you want a faster feeling without making the architecture messy

For me, this is the sweet spot: Alpine for the interaction edge, Livewire for the server-backed truth, and just enough optimism to make the whole thing feel alive.

1. The “Senior” Myth: Masters of Laravel or Secret Googlers?

If you think seniors know it all, let’s debunk that myth. Just picture this: a “seasoned” developer with ten years in Laravel who’s secretly searching, “why is my Livewire component loading three times?” Yep, they’re Googling, just like everyone else. Sometimes, a senior needs a senior just to swap “war stories” and realize they’re all just making it up as they go along.

A senior developer is just a junior with a decade of Stack Overflow tabs open.

2. Livewire Mysteries: When “Reactive” Gets Too Real

Livewire might be magical, but sometimes it’s just plain confusing. One minute you’re building a clean component, and the next, you’re asking yourself, “Why is this thing alive in every browser tab?” This is where another senior steps in, nodding knowingly and sharing that one trick they learned three projects ago.

Livewire’s reactivity: where one refresh turns into a chain reaction, and you’ve started a browser revolution.

3. Middleware Mania: A Journey into the Layers

One of the rites of passage for any Laravel developer is wrangling with middleware. But even seniors get stuck in that middleware labyrinth! When a simple route suddenly takes a trip down Middleware Lane, even the pros need someone to guide them out. Because let’s face it, sometimes even the best seniors get tangled up in their own webs.

A senior without backup is like a Laravel route without middleware… eventually, you’re exposed

4. Package Wonderland: New, Shiny, and Confusing

Every Laravel senior knows the joy of finding a shiny new package. And then comes the installation… “Wait, this isn’t working like the docs said!” This is the moment when having another senior’s input makes all the difference, turning “What is going on?” into, “Oh, let’s try this clever hack instead!”

Package installs are a thrill ride: up, up, and then… down into the rabbit hole of dependencies.

5. Even the Pros Love Fresh Perspectives

Laravel’s ecosystem is vast, and Livewire makes it exciting—but sometimes tricky. Having another senior, or even a keen junior, brings in fresh perspectives. Together, they can solve problems faster and maybe even discover new ways of doing things (or at least share a laugh over what doesn’t work!).

The best seniors never stop learning—and occasionally, they even ask juniors for the latest shortcut.

Final Thought: Even in the world of Laravel and Livewire, a senior benefits from having another senior around. So here’s to all the developers, from juniors to seniors—may we all keep learning, laughing, and Googling together!

You can use dynamic tagging and runtime resolution to select implementations on the fly, making your services incredibly flexible without hardcoding anything.

The Hack

1. Define a Base Interface

Let’s say you have an interface for payment gateways:

1namespace App\Contracts;
2 
3interface PaymentGateway
4{
5    public function process($amount);
6}

1namespace App\Contracts;
2 
3interface PaymentGateway
4{
5    public function process($amount);
6}

2. Create Multiple Implementations

Define a couple of implementations for this interface:

 1namespace App\Services\Payments;
 2 
 3use App\Contracts\PaymentGateway;
 4 
 5class StripeGateway implements PaymentGateway
 6{
 7    public function process($amount)
 8    {
 9        return "Processing {$amount} via Stripe!";
10    }
11}
12 
13class PayPalGateway implements PaymentGateway
14{
15    public function process($amount)
16    {
17        return "Processing {$amount} via PayPal!";
18    }
19}

 1namespace App\Services\Payments;
 2 
 3use App\Contracts\PaymentGateway;
 4 
 5class StripeGateway implements PaymentGateway
 6{
 7    public function process($amount)
 8    {
 9        return "Processing {$amount} via Stripe!";
10    }
11}
12 
13class PayPalGateway implements PaymentGateway
14{
15    public function process($amount)
16    {
17        return "Processing {$amount} via PayPal!";
18    }
19}

3. Tag Services in a Service Provider

In your AppServiceProvider, tag these implementations dynamically:

 1use App\Contracts\PaymentGateway;
 2use App\Services\Payments\StripeGateway;
 3use App\Services\Payments\PayPalGateway;
 4 
 5public function register()
 6{
 7    $this->app->bind(StripeGateway::class, fn () => new StripeGateway());
 8    $this->app->bind(PayPalGateway::class, fn () => new PayPalGateway());
 9 
10    // Dynamically tag both services
11    $this->app->tag([StripeGateway::class, PayPalGateway::class], 'payment_gateways');
12}

 1use App\Contracts\PaymentGateway;
 2use App\Services\Payments\StripeGateway;
 3use App\Services\Payments\PayPalGateway;
 4 
 5public function register()
 6{
 7    $this->app->bind(StripeGateway::class, fn () => new StripeGateway());
 8    $this->app->bind(PayPalGateway::class, fn () => new PayPalGateway());
 9 
10    // Dynamically tag both services
11    $this->app->tag([StripeGateway::class, PayPalGateway::class], 'payment_gateways');
12}

4. Resolve Dynamically Based on Logic

Now you can resolve and switch between implementations at runtime based on dynamic conditions:

 1use Illuminate\Contracts\Container\Container;
 2 
 3function getPaymentGateway(Container $container, $preferredGateway): PaymentGateway
 4{
 5    $gateways = $container->tagged('payment_gateways');
 6 
 7    foreach ($gateways as $gateway) {
 8        if (get_class($gateway) === $preferredGateway) {
 9            return $gateway;
10        }
11    }
12 
13    throw new \Exception("No gateway found for {$preferredGateway}");
14}
15 
16// Example usage
17$gatewayClass = \App\Services\Payments\StripeGateway::class; // Could come from config or runtime logic
18 
19$gateway = getPaymentGateway(app(), $gatewayClass);
20 
21echo $gateway->process(100); // Outputs: Processing 100 via Stripe!

 1use Illuminate\Contracts\Container\Container;
 2 
 3function getPaymentGateway(Container $container, $preferredGateway): PaymentGateway
 4{
 5    $gateways = $container->tagged('payment_gateways');
 6 
 7    foreach ($gateways as $gateway) {
 8        if (get_class($gateway) === $preferredGateway) {
 9            return $gateway;
10        }
11    }
12 
13    throw new \Exception("No gateway found for {$preferredGateway}");
14}
15 
16// Example usage
17$gatewayClass = \App\Services\Payments\StripeGateway::class; // Could come from config or runtime logic
18 
19$gateway = getPaymentGateway(app(), $gatewayClass);
20 
21echo $gateway->process(100); // Outputs: Processing 100 via Stripe!

5. Bonus Hack: Auto-Tag Based on Folder Scanning

Let’s take it a step further and auto-tag classes in a folder:

 1use Illuminate\Support\Facades\File;
 2 
 3public function register()
 4{
 5    $paymentServices = collect(File::allFiles(app_path('Services/Payments')))
 6        ->map(fn ($file) => 'App\\Services\\Payments\\' . $file->getFilenameWithoutExtension())
 7        ->filter(fn ($class) => class_exists($class))
 8        ->each(fn ($class) => $this->app->bind($class, fn () => new $class()));
 9 
10    $this->app->tag($paymentServices->all(), 'payment_gateways');
11}

 1use Illuminate\Support\Facades\File;
 2 
 3public function register()
 4{
 5    $paymentServices = collect(File::allFiles(app_path('Services/Payments')))
 6        ->map(fn ($file) => 'App\\Services\\Payments\\' . $file->getFilenameWithoutExtension())
 7        ->filter(fn ($class) => class_exists($class))
 8        ->each(fn ($class) => $this->app->bind($class, fn () => new $class()));
 9 
10    $this->app->tag($paymentServices->all(), 'payment_gateways');
11}

Now, any new class in App\Services\Payments is automatically tagged and ready to use.

The last one is likely my fault; I am sorry.

Let’s challenge your thinking on queries and see if we can’t clear up this Laravel function mess I have put us in.

Are slow database queries bad?

Some queries are just inherently slow and as optimized as they are gonna get. That is fine, but...

I think we can agree that slow queries are generally bad. Maybe "bad" isn’t the right word. Perhaps "not ideal" is better.

Slow database queries are not ideal. Yea. That's better.

But how do we even define "slow"?

We could compare two queries, e.g., a 50ms query verses a 2s query. In this case the 2 second query is slow (without knowing any context about the query).

Alternatively, instead of comparing two queries, we might explicitly define what a "slow" query is within our system by setting an explicit threshold via the Slow Query Log feature of the database. This allows us to operationalise what we consider a slow query.

Why don’t we set our imaginary slow query threshold to 1 second. Anything over 1 second we will classify as slow, for the purpose of the post.

Our slow query log will now record queries over 1 second. If the logs are filling up, we know we have slow queries and can try to address them.

Well that wasn’t all too exciting. So let’s talk about fast database queries…

Are fast queries good?

Are they? What makes them good? In what context are we talking?

I’d have a guess and say you feel they are good because they indicate your application is fast, at least when it comes to querying the database.

In isolation: fast database queries are good.

But I don't deal with queries in isolation. I work on web apps that have rich interactions with potentially multiple queries happening within a single HTTP request lifecycle, queued job, or artisan command.

If we were to use comparison as our measure again: a HTTP request that queries the database for 5ms is better than a HTTP request that queries the database for 1.5 seconds, right?

I think it is, in regards to resource usage at least.

What if I make a HTTP request and there are no logs in my slow query log, is that good?

I don’t think so. I don’t think it’s bad, but I don’t think it’s evidence of "good" either.

After all, what information do we actually have with an empty slow query log?

We know that the HTTP request did not perform any queries over 1 second. This sounds good, but it isn’t enough information to work with.

What if our HTTP request executed the following code. Forgive the extreme example.

1use App\Models\User;
2 
3$endAt = now()->addSeconds(20);
4 
5while ($endAt->isFuture()) {
6    User::first();
7}

1use App\Models\User;
2 
3$endAt = now()->addSeconds(20);
4 
5while ($endAt->isFuture()) {
6    User::first();
7}

The above code executes a very fast database query, however it executes the query in a non-stop loop for 20 seconds. Of course this is a contrived example, but I've certainly worked in applications where, for example, checking feature flags made hundreds, and sometimes thousands, of "fast" database queries throughout a single HTTP request.

If the above code was executed within a HTTP request to my application, there are a few facts that reveal themselves:

1. I am a psychopath.
2. My slow query log will be empty.

These queries are fast; These queries are not good

So fast queries are not indicative of "good" in this particular context. The slow query log only goes so far.

What I really want to do, in order to make my HTTP requests fast, is to spend less time in the database for my overall request. I care about the "cumulative query time" for the request.

If I make one 2 second query or four 0.5 second queries, they both make my HTTP request slower by 2 seconds and, from an end-user perspective, are both just as slow as each other.

So what can we do? Well, now I'm gonna reach for my sharp hammer: Laravel.

Measuring query time with Laravel

I’m gonna show you a thing. This isn’t the thing. This is a thing, and a thing to cover, but it isn’t the thing. So I’ll try and be brief.

Laravel has a way to listen for queries and check their duration. We could, for example, emulate the slow query log with something like the following:

 1use Illuminate\Database\Events\QueryExecuted;
 2use Illuminate\Support\Facades\Event;
 3use Illuminate\Support\Facades\Log;
 4 
 5Event::listen(QueryExecuted, function (QueryExecuted $event) {
 6    if ($event->time > 1000) {
 7        Log::info('Slow query detected.', [
 8            // ...
 9        ]);
10    }
11});

 1use Illuminate\Database\Events\QueryExecuted;
 2use Illuminate\Support\Facades\Event;
 3use Illuminate\Support\Facades\Log;
 4 
 5Event::listen(QueryExecuted, function (QueryExecuted $event) {
 6    if ($event->time > 1000) {
 7        Log::info('Slow query detected.', [
 8            // ...
 9        ]);
10    }
11});

If any individual query made by Laravel is over the 1 second threshold it will log "Slow query detected." to the application log. If 5 queries in a single HTTP request all take over 1 second it will log this message 5 times.

This does not give us anything new and moving it to Laravel is fine, but not ideal.

But knowing this technique is relevant to help us differentiate what we are about to talk about.

Measuring cumulative query time with Laravel

A little while ago I added a method to Laravel. You might have seen this method:

1use Illuminate\Database\Connection;
2use Illuminate\Support\Facades\DB;
3 
4DB::whenQueryingForLongerThan(1000, function (Connection $connection) {
5    Log::info('Queries collectively took longer than 1 second.', [
6        // ...
7    ]);
8});

1use Illuminate\Database\Connection;
2use Illuminate\Support\Facades\DB;
3 
4DB::whenQueryingForLongerThan(1000, function (Connection $connection) {
5    Log::info('Queries collectively took longer than 1 second.', [
6        // ...
7    ]);
8});

You might be forgiven for assuming that this handler and the previous query log emulation example were the same, i.e., if a query takes longer than 1 second to execute than the provided closure is called.

You would be forgiven because multiple people have told me they thought that is what it did.

But they are not the same. The first event listener example only considers a single query in isolation, while this new handler considers the context of the entire HTTP request.

To show the difference, let’s register both of these in our imaginary application’s service provider. We’ll continue to use 1 second for our logging threshold.

 1use Illuminate\Database\Connection;
 2use Illuminate\Database\Events\QueryExecuted;
 3use Illuminate\Support\Facades\Auth;
 4use Illuminate\Support\Facades\DB;
 5use Illuminate\Support\Facades\Event;
 6use Illuminate\Support\Facades\Log;
 7use Illuminate\Support\Facades\Request;
 8 
 9/*
10 * Log when any query exceeds one second in duration.
11 */
12Event::listen(QueryExecuted, function (QueryExecuted $event) {
13    if ($event->time > 1000) {
14       Log::info('Query took longer than 1 second.', [
15           // ...
16       ]);
17    }
18});
19 
20/*
21 * Log when all queries collectivly exceed one second in duration.
22 */
23DB::whenQueryingForLongerThan(1000, function (Connection $connection) {
24    Log::info('Queries collectively took longer than 1 second.', [
25        // ...
26    ]);
27});

 1use Illuminate\Database\Connection;
 2use Illuminate\Database\Events\QueryExecuted;
 3use Illuminate\Support\Facades\Auth;
 4use Illuminate\Support\Facades\DB;
 5use Illuminate\Support\Facades\Event;
 6use Illuminate\Support\Facades\Log;
 7use Illuminate\Support\Facades\Request;
 8 
 9/*
10 * Log when any query exceeds one second in duration.
11 */
12Event::listen(QueryExecuted, function (QueryExecuted $event) {
13    if ($event->time > 1000) {
14       Log::info('Query took longer than 1 second.', [
15           // ...
16       ]);
17    }
18});
19 
20/*
21 * Log when all queries collectivly exceed one second in duration.
22 */
23DB::whenQueryingForLongerThan(1000, function (Connection $connection) {
24    Log::info('Queries collectively took longer than 1 second.', [
25        // ...
26    ]);
27});

Then we will make a HTTP request to the endpoint with our terrible code again. I've duplicated it here for your personal pain and suffering - and as a friendly reminder.

1use App\Models\User;
2 
3$endAt = now()->addSeconds(20);
4 
5while ($endAt->isFuture()) {
6    User::first();
7}

1use App\Models\User;
2 
3$endAt = now()->addSeconds(20);
4 
5while ($endAt->isFuture()) {
6    User::first();
7}

Now something interesting will happen when this HTTP request is finished:

1. My slow query log will be empty.
2. Our application’s log will not contain any "Slow query detected." entries
3. Our application log will, however, contain a single "Queries collectively took longer than 1 second." entry.

This is because the whenQueryingForLongerThan feature will keep track of all queries made during a single HTTP request lifecycle. If many fast queries are made that, when added together, take longer than one second the closure will be called and it will only ever be called once per HTTP request lifecycle.

This allows us to detect and log when many fast queries cause our HTTP requests to be slow 🎉

See! Fast queries can be bad!

This feature doesn’t just work for HTTP requests. It also works for queued jobs, where the closure is called once per job lifecycle.

It’s pretty neat, but I always felt it needed a better name to make it more obvious how it deviates from the alternative QueryExecuted event listener set up.

So that’s what this post is. This post is, in its entirety, the new method name.

Remember that none of this is a replacement for the database’s slow query log. The database's slow query log is an important tool to dive into and learn about.

Fun fact: the MySQL slow query log limit is 365 days. It’s like they knew I might be crafting queries 😆

Further reading

• DB::whenQueryingForLongerThan documentation
• MySQL slow query log documentation

Stage 1: Developer Life – All Code, All Day

Back in the good ol’ days, I was living and breathing code. My world was filled with Tailwind CSS, Alpine.js, Vue.js, Laravel—you name it. If there was an acronym, I probably worked with it.

Every day I was building features like:

1public function buildCoolFeature()
2{
3    // Logic here to make users happy
4    return success();
5}

1public function buildCoolFeature()
2{
3    // Logic here to make users happy
4    return success();
5}

I didn’t care much about meetings or management; just give me a coffee, and I could ship code like nobody’s business. Life was good!

But then… things started to change.

Stage 2: My First Intern – The Mentor Awakens

The real turning point came when I was asked to mentor an intern. Intern? Like, you want me to explain what I do… to someone else? Oh boy. But I took the challenge head-on and suddenly found myself explaining complex code like:

1// What I told my intern:
2$coffee = makeCoffee();
3 
4// What they heard:
5💡☕️🤯

1// What I told my intern:
2$coffee = makeCoffee();
3 
4// What they heard:
5💡☕️🤯

Surprisingly, mentoring wasn’t so bad. I mean, yeah, it was like teaching a toddler to code at times, but seeing them grow into actual developers made me feel like a proud parent. The debugging sessions were goldmines of life lessons… and occasional disasters.

Stage 3: The Promotion – More Responsibilities, More Coffee

Then one day, they threw the big title at me: Senior Manager with Developer Responsibilities. Suddenly, I wasn’t just responsible for my own code anymore. Nope, now I had to manage other people’s code. Yikes!

Meetings started creeping into my calendar like unexpected bugs in production:

1// Old daily schedule:
2$tasks = [ 'coding', 'debugging', 'fixing things' ];
3 
4// New daily schedule:
5$tasks = [ 'meetings', 'more meetings', 'asking devs why it’s still broken' ];

1// Old daily schedule:
2$tasks = [ 'coding', 'debugging', 'fixing things' ];
3 
4// New daily schedule:
5$tasks = [ 'meetings', 'more meetings', 'asking devs why it’s still broken' ];

Stage 4: Team Management – The Art of Debugging People

Turns out, managing a team isn’t that different from writing code. You just replace semicolons with people’s emotions.

One day, your junior dev is super productive, smashing out PRs. The next day, they're asking you what “git” is. So, I had to learn how to be flexible:

1// New responsibilities as a manager:
2if (devsAreStuck()) {
3    // Try turning it off and on again (the dev, not the code)
4    giveEncouragement();
5} else {
6    // When things are magically working
7    justSmileAndNod();
8}

1// New responsibilities as a manager:
2if (devsAreStuck()) {
3    // Try turning it off and on again (the dev, not the code)
4    giveEncouragement();
5} else {
6    // When things are magically working
7    justSmileAndNod();
8}

Stage 5: Balancing Code and Chaos – The Daily Grind

Balancing coding with management is like trying to deploy on a Friday—risky but sometimes necessary. Some days, I’m deep in code. Other days, I’m figuring out why half the team’s in a Slack battle over the most efficient way to name a variable.

As a senior manager, it’s my job to make sure the team runs smoothly:

1function keepTeamHappy()
2{
3    // Main function for a successful team
4    while (teamProductivity < 100) {
5        encourage();
6        drinkCoffee();
7        debug();
8    }
9}

1function keepTeamHappy()
2{
3    // Main function for a successful team
4    while (teamProductivity < 100) {
5        encourage();
6        drinkCoffee();
7        debug();
8    }
9}

The trick is staying connected to both worlds. I still code, mentor, and review PRs, but now I also navigate the tricky waters of people management.

Final Stage: Lessons Learned – Lead with Humor, and Maybe Coffee

Here’s what I’ve learned on this journey from developer to senior manager:

1. Code is easy, people are hard: Debugging a null pointer error? Easy. Figuring out why Bob from QA keeps using tabs instead of spaces? That’s the real challenge.
2. Mentoring is like pair programming, but with emotions: Explaining code to someone new is the best way to remind yourself how little you understand. But it’s also incredibly rewarding.
3. Coffee powers everything: Whether it’s fixing bugs or attending meetings, coffee is the fuel. Seriously, it should come with the title.
4. Take a break, laugh at yourself: This job can be stressful, so it’s important to laugh—at your mistakes, at your team’s memes, and definitely at the inevitable “works on my machine” excuses.

Conclusion: Becoming a senior manager with developer responsibilities has been a wild ride. From writing code to mentoring interns and leading a team, it’s been a journey of growth, patience, and, yes, a whole lot of coffee.

So, if you’re thinking about stepping into management, just remember: it’s like being a developer… except now you’re debugging humans, too.

Inside that card, you also add a tiny button to open a dialog.

Here’s the thing: because the whole card is wrapped in a navigation click, that little button doesn’t stand a chance. Users try to open the dialog… and boom. they’re already on the next page.

I didn’t go hunting strangers or asking every developer forum to bless me. I opened the docs and figured it out.

Livewire Navigation Docs

Before: The Unwanted Navigation

Typical structure:

 1<a
 2    wire:navigate
 3    href="{{ route('target.route', ['param' => $param->id]) }}"
 4    x-data="{ dialogOpen: false }"
 5    class="block rounded-2xl border border-zinc-200 p-5"
 6>
 7    <div class="flex items-start justify-between gap-4">
 8        <div>
 9            <h3 class="text-lg font-semibold">Action Title</h3>
10            <p class="mt-1 text-sm text-zinc-600">
11                Tap anywhere on the card to continue.
12            </p>
13        </div>
14 
15        <button
16            type="button"
17            x-on:click="dialogOpen = true"
18            class="inline-flex h-9 w-9 items-center justify-center rounded-full border"
19        >
20            <x-lucide-info class="h-4 w-4" />
21        </button>
22    </div>
23 
24    <div x-show="dialogOpen" class="dialog-panel">
25        <p>Extra context for the user.</p>
26    </div>
27</a>

 1<a
 2    wire:navigate
 3    href="{{ route('target.route', ['param' => $param->id]) }}"
 4    x-data="{ dialogOpen: false }"
 5    class="block rounded-2xl border border-zinc-200 p-5"
 6>
 7    <div class="flex items-start justify-between gap-4">
 8        <div>
 9            <h3 class="text-lg font-semibold">Action Title</h3>
10            <p class="mt-1 text-sm text-zinc-600">
11                Tap anywhere on the card to continue.
12            </p>
13        </div>
14 
15        <button
16            type="button"
17            x-on:click="dialogOpen = true"
18            class="inline-flex h-9 w-9 items-center justify-center rounded-full border"
19        >
20            <x-lucide-info class="h-4 w-4" />
21        </button>
22    </div>
23 
24    <div x-show="dialogOpen" class="dialog-panel">
25        <p>Extra context for the user.</p>
26    </div>
27</a>

Everything looks correct… but a button inside a clickable navigation wrapper = accidental page changes.

You click the info button ➜ navigation fires anyway because the click event bubbles up to <a wire:navigate>.

After: Full Control Navigation Only When You Decide

Instead of letting wire:navigate automatically trigger, we call it manually using Livewire.navigate().

 1+ @script
 2+     <script>
 3+         window.redirectToTarget = () => {
 4+             Livewire.navigate(@js(route('target.route', ['param' => $param->id])))
 5+         }
 6+     </script>
 7+ @endscript
 8 
 9- <div
10-     x-data="{ dialogOpen: false }"
11+     x-on:click="redirectToTarget"
12-     class="clickable-card"
13- >
14-     <h3>
15-         Action Title
16-         <button
17-             type="button"
18-             x-on:click.stop.prevent="dialogOpen = true"
19-         >
20-             <x-lucide-info />
21-         </button>
22-     </h3>
23-
24-     <p>Short description text</p>
25-
26-     <div x-show="dialogOpen" class="dialog-panel">
27-         <h2>Dialog Title</h2>
28-         <p>More info goes here.</p>
29-         <button type="button" x-on:click="dialogOpen = false">Close</button>
30-     </div>
31- </div>

 1+ @script
 2+     <script>
 3+         window.redirectToTarget = () => {
 4+             Livewire.navigate(@js(route('target.route', ['param' => $param->id])))
 5+         }
 6+     </script>
 7+ @endscript
 8 
 9- <div
10-     x-data="{ dialogOpen: false }"
11+     x-on:click="redirectToTarget"
12-     class="clickable-card"
13- >
14-     <h3>
15-         Action Title
16-         <button
17-             type="button"
18-             x-on:click.stop.prevent="dialogOpen = true"
19-         >
20-             <x-lucide-info />
21-         </button>
22-     </h3>
23-
24-     <p>Short description text</p>
25-
26-     <div x-show="dialogOpen" class="dialog-panel">
27-         <h2>Dialog Title</h2>
28-         <p>More info goes here.</p>
29-         <button type="button" x-on:click="dialogOpen = false">Close</button>
30-     </div>
31- </div>

Why This Works

• The card itself controls navigation using redirectToTarget()
• The dialog button stops the click from bubbling up (.stop.prevent)
• You decide when navigation should fire not the browser

No hacks. No overlays. Just letting Alpine handle UI, and Livewire handle navigation independently.

Key Lesson

When combining Alpine interactions inside click-based navigation:

• Stop clicks meant for UI elements
• Trigger navigation programmatically
• Keep control where it belongs

Sometimes the cleanest solution starts with simply reading the docs.

Git is one of the most powerful tools in a developer’s toolkit — and while we all use it, few of us use it to its full potential. In my talk at the Laravel Ahmedabad meetup, I dived deep into one of Git’s most underrated and misunderstood features: rebase.

In this blog post, I’ll summarize the key points from my talk, share practical tips, and link to the slides for those who missed it.

Why Learn git rebase?

Many developers stick to git merge because it’s safer and easier to understand. But learning how to rebase can help you:

• Keep your commit history clean and linear.
• Avoid unnecessary merge commits.
• Make code review easier for your team.
• Squash and reword commits before pushing to main branches.

Understanding the Basics

Merge vs Rebase

• Merge: Combines two branches, preserving both histories.
• Rebase: Rewrites your commits to apply them on top of another base commit.

1# Typical use
2git rebase main

1# Typical use
2git rebase main

This moves your feature branch commits to be "on top of" the latest main.

Live Demo Highlights

Here’s what we walked through in the session:

1. Rebase a Feature Branch

1git checkout feature-xyz
2git fetch origin
3git rebase origin/main

1git checkout feature-xyz
2git fetch origin
3git rebase origin/main

2. Squash Commits Before Merging

1git rebase -i HEAD~3

1git rebase -i HEAD~3

Pick, squash, and reword commits interactively.

3. Abort a Rebase

1git rebase --abort

1git rebase --abort

4. Continue Rebase After Conflict Resolution

1# Resolve conflicts
2git add .
3git rebase --continue

1# Resolve conflicts
2git add .
3git rebase --continue

Rebase in Pull Requests

Here’s a great workflow to keep your PRs clean:

1git checkout feature-abc
2git fetch origin
3git rebase origin/main
4git push --force-with-lease

1git checkout feature-abc
2git fetch origin
3git rebase origin/main
4git push --force-with-lease

Note: Use --force-with-lease instead of --force to avoid overwriting others’ changes on shared branches.

When NOT to Rebase

Never rebase shared or public branches that others are working on.

Rebase rewrites history. Do it only on local branches or branches you control.

Slides from the Talk

You can view or download the slides here: Rebase Like a Pro: Slide Deck (Livewire app)

Wrap Up

Rebasing is a superpower once you master it. It’s cleaner, smarter, and can seriously improve your Git hygiene. especially in collaborative Laravel projects.

Have any questions or want to dive deeper into Git workflows? Drop me a message on Twitter or GitHub!

Tools Mentioned

• Git CLI
• GitLens (VS Code Extension)
• GitHub / GitLab UI for rebase & squash

A tiny script I created allowed me to verify, with certainty, that I had not modified any route definitions after a pretty decent-sized refactor that touched a lot of different parts of the application. I thought it was pretty neat and gave me a lot of confidence to ship the changes, so I thought I would share.

In a project I’m working on there are duplicated middleware added to a lot of routes. At some point, in this projects long life, the way middleware was added to routes was moved from controller constructor middleware to the route file middleware (where they belong 😎).

If you aren’t familiar with these two options for adding middleware to a route, Laravel allows you to add middleware in a routes file...

 1// routes/web.php
 2 
 3use App\Http\Middleware\Authenticate;
 4use App\Http\Middleware\MonitorUsage;
 5use Illuminate\Support\Facades\Route;
 6 
 7// Apply middleware to a group of routes...
 8Route::middleware(Authenticate::class)->group(function () {
 9 
10    // Apply middleware to a single route...
11    Route::get(/* ... */)->middleware(MonitorUsage::class);
12});

 1// routes/web.php
 2 
 3use App\Http\Middleware\Authenticate;
 4use App\Http\Middleware\MonitorUsage;
 5use Illuminate\Support\Facades\Route;
 6 
 7// Apply middleware to a group of routes...
 8Route::middleware(Authenticate::class)->group(function () {
 9 
10    // Apply middleware to a single route...
11    Route::get(/* ... */)->middleware(MonitorUsage::class);
12});

Laravel also allows you to add middleware to routes via the controller’s constructor. These middleware will apply to all methods on the controller unless otherwise configured.

 1namespace App\Http\Controllers;
 2 
 3use App\Http\Middleware\Authenticate;
 4use App\Http\Middleware\MonitorUsage;
 5 
 6class UserController extends Controller
 7{
 8    public function __construct()
 9    {
10        $this->middleware(Authenticate::class);
11        $this->middleware(MonitorUsage::class, ['only' => 'show']);
12    }
13 
14    // ...
15}

 1namespace App\Http\Controllers;
 2 
 3use App\Http\Middleware\Authenticate;
 4use App\Http\Middleware\MonitorUsage;
 5 
 6class UserController extends Controller
 7{
 8    public function __construct()
 9    {
10        $this->middleware(Authenticate::class);
11        $this->middleware(MonitorUsage::class, ['only' => 'show']);
12    }
13 
14    // ...
15}

As I mentioned, this project had moved from using controller middleware to route file middleware, however the middleware in the controllers had not yet been tidied up and removed.

This wasn’t really a problem.

It wasn’t like these middleware were being run twice. Laravel deduplicates middleware applied to a route, i.e., if we add the same middleware to a route more than once it is only executed once.

We can see this with a quick example. I'll create an empty middleware that dumps a message when it is run.

 1namespace App\Http\Middleware;
 2 
 3class MyMiddleware
 4{
 5    public function handle($request, $next)
 6    {
 7        dump('Running my middleware.');
 8 
 9        return $next($request);
10    }
11}

 1namespace App\Http\Middleware;
 2 
 3class MyMiddleware
 4{
 5    public function handle($request, $next)
 6    {
 7        dump('Running my middleware.');
 8 
 9        return $next($request);
10    }
11}

I can then create a route and apply the middleware to it twice; once via a wrapping group and once on the actual route itself.

1// routes/web.php
2 
3use App\Middleware\MyMiddleware;
4use Illuminate\Support\Facades\Route;
5 
6Route::middleware(MyMiddleware::class)->group(function () {
7    Route::get('/', fn () => 'Welcome!')->middleware(MyMiddleware::class);
8});

1// routes/web.php
2 
3use App\Middleware\MyMiddleware;
4use Illuminate\Support\Facades\Route;
5 
6Route::middleware(MyMiddleware::class)->group(function () {
7    Route::get('/', fn () => 'Welcome!')->middleware(MyMiddleware::class);
8});

When we access this page we see the following output rendered in the browser. You will notice that the dump is only seen once, indicating that Laravel has removed the duplicate middleware from the stack.

So cleaning this up was about aesthetics and consistency - or so I thought!

I decided to finally dig in and refactor it away. I came up with a plan and started doing a, rather manual, systematic route-by-route check.

1. Look at the route.
2. Work out the applied middleware in the routes file.
3. Move to the controller constructor.
4. Verify the middleware applied matched or was at least a subset of the route file middleware.
5. Remove the middleware from the constructor.
6. Make any required adjustments in the route file.

I did this for about 2 minutes before it dawned on me that whoever reviews this is gonna have a bad time. We would either YOLO it into production and hope the testsuite caught any issues or some poor soul would have to do all this manual checking again while reviewing. Not a fun time.

It wasn’t worth the time / improvement trade off.

I stopped coding; I moved away from the keyboard; I thought…

Do I scrap the changes? It’s not hurting anyone…but it did hurt me. Won’t somebody think of the children!

Then I realised I could potentially automate the review process and MAKE THE ROBOTS DO IT 🤖

Laravel ships with an artisan command that displays all routes defined within the application. There are a few flags on the command to change the commands output.

The bare command, php artisan route:list, will show you the routes.

But this doesn’t show the route middleware. Using the verbose flag, php artisan route:list -v, will show middleware for each route.

Great! We are getting somewhere useful! I then remembered that a --json flag was available on the command to output a JSON representation of the routes and their middleware instead of the visual representation we see in the terminal.

With the combination of all of this I could get all the routes and their respective middleware output before I made the change and then compare the file to the routes after I made the change.

So no more route-by-route review; I went straight for the jugular and stripped out all the middleware from all the controllers in a matter of minutes.

I committed my changes to my working branch.

I crafted the following helper script.

1git checkout main
2php artisan route:list --json -v | jq > before.json
3 
4git checkout working
5php artisan route:list --json -v | jq > after.json

1git checkout main
2php artisan route:list --json -v | jq > before.json
3 
4git checkout working
5php artisan route:list --json -v | jq > after.json

The content of the before.json and after.json files now looks something like the following, which has been truncated for brevity...

 1[
 2  {
 3    "domain": null,
 4    "method": "GET|HEAD",
 5    "uri": "/",
 6    "name": null,
 7    "action": "Closure",
 8    "middleware": ["web"]
 9  },
10  {
11    "domain": null,
12    "method": "GET|HEAD",
13    "uri": "api/user",
14    "name": null,
15    "action": "Closure",
16    "middleware": ["api", "App\\Http\\Middleware\\Authenticate:sanctum"]
17  },
18  {
19    "domain": null,
20    "method": "GET|HEAD",
21    "uri": "confirm-password",
22    "name": "password.confirm",
23    "action": "App\\Http\\Controllers\\Auth\\ConfirmablePasswordController@show",
24    "middleware": ["web", "App\\Http\\Middleware\\Authenticate"]
25  }
26  // ...
27]

 1[
 2  {
 3    "domain": null,
 4    "method": "GET|HEAD",
 5    "uri": "/",
 6    "name": null,
 7    "action": "Closure",
 8    "middleware": ["web"]
 9  },
10  {
11    "domain": null,
12    "method": "GET|HEAD",
13    "uri": "api/user",
14    "name": null,
15    "action": "Closure",
16    "middleware": ["api", "App\\Http\\Middleware\\Authenticate:sanctum"]
17  },
18  {
19    "domain": null,
20    "method": "GET|HEAD",
21    "uri": "confirm-password",
22    "name": "password.confirm",
23    "action": "App\\Http\\Controllers\\Auth\\ConfirmablePasswordController@show",
24    "middleware": ["web", "App\\Http\\Middleware\\Authenticate"]
25  }
26  // ...
27]

The only thing needed now was to compare the two files and see what the damage is. Of course I don't want this to be a manual process either! This step is why I wanted the JSON formatted nicely. If it was all a single line it would be impossible to see the difference. With formatted JSON I can use some tooling to see the exact differences before and after the refactor.

My tool of choice here is the diffing tool built into Kitty, the terminal I use, but you could use any diffing tool you have access to.

1diff <(jq --sort-keys . before.json) <(jq --sort-keys . after.json)

1diff <(jq --sort-keys . before.json) <(jq --sort-keys . after.json)

The result was something that look liked the following...

This gave me a way to visualise, with precision, the differences between each route's middleware before and after the change and detect inconsistecies.

I found this super valuable.

I ended up finding a few differences that were inconsistencies between the contructor and route file middleware - so it turns out it wasn't just aesthetics and consistency but actually help identify some places where our constructor middleware was lying to us.

So a PR with 548 deletions and 359 additions across 111 files was easily merge without manual testing.

Why do you care? Because now you can migrate your middleware to the routes file and also completely refactor your routes file to remove the use of Route::prefix and have a flat routes file, the way it should be, without worrying about breaking everything 😎

But hopefully it also gives you some ideas of how you could create single-use tests for your own PRs.

Monday: The "12-Hour Shift Marathon" 🕛

Monday kicked off strong. By strong, I mean 12 hours of non-stop work. I think my chair now has an imprint of my soul. 😅 Every time I thought I was done, something else popped up! But hey, at least I managed to tackle some Laravel domain work. Writing domain logic? Easy peasy! 💻

1// Laravel domain stuff — smooth as butter!
2public function handleDomainStuff($request)
3{
4    return DomainLogic::process($request);
5}

1// Laravel domain stuff — smooth as butter!
2public function handleDomainStuff($request)
3{
4    return DomainLogic::process($request);
5}

Then came the real challenge...

Tuesday: Google Authentication, but with a Twist 🧩

You know how Laravel Socialite makes Google authentication sound like a breeze? Well, it is... unless you're dealing with multiple domains and a central point of failure. Trying to manage Socialite redirects across different domains was like trying to teach a cat to play fetch. 🐱

1use Laravel\Socialite\Facades\Socialite;
2 
3// Seems easy, but not with multi-domain redirects!
4public function redirectToGoogle()
5{
6    return Socialite::driver('google')->redirect();
7}

1use Laravel\Socialite\Facades\Socialite;
2 
3// Seems easy, but not with multi-domain redirects!
4public function redirectToGoogle()
5{
6    return Socialite::driver('google')->redirect();
7}

Pro tip: Remember to triple-check your redirect URIs, or you'll be pulling your hair out wondering why Google thinks you're an imposter.

Interns, Interns Everywhere! 😵

And don’t get me started on managing interns while juggling all this. I spent more time explaining the difference between git fetch and git pull than I did coding. At this rate, I’ll be adding Intern Wrangler to my LinkedIn profile.

Wednesday to Friday was basically more of the same, but with slightly fewer hours and more coffee.

Friday: Wrapping Up with a Smile 😎

By Friday, I was down to a solid 8 hours, but still, no day off in sight! My weekend plan? Sleep. 💤

Conclusion? Multi-domain authentication isn’t for the faint-hearted, but hey, if I can survive this week, I can survive anything! 🎉

Hope you enjoyed the chaos! Time to treat myself to a well-deserved break... or at least a second cup of coffee. ☕