In Livewire, how does one component notify another with dispatch() and #[On], and how do to() and self() narrow who receives the event?

## Why components need events In Livewire, **every component is independent**: an update to one component sends only that component's state to the server and re-renders only that component. So when a product card adds an item to the cart, the **cart counter in the header**, a separate component, has no idea anything changed. Events are the loosely coupled way to tell it. ## Dispatching and listening ```php // Product card: an action dispatches after changing the cart public function addItem(Product $product): void { Cart::for(auth()->user())->add($product); $this->dispatch('cart-updated', count: Cart::for(auth()->user())->count()); } ``` ```php use Livewire\Attributes\On; // Header cart counter public int $count = 0; #[On('cart-updated')] public function refreshCount(int $count): void { $this->count = $count; } ``` - `dispatch()` takes the event name and **named parameters**; the listener method receives them **by parameter name**. - `#[On('...')]` (import `Livewire\Attributes\On`) registers a public method as a listener. A component only reacts to events it has registered; an unregistered name fails with an event-handler-does-not-exist error. ## What actually happens, step by step 1. The product card's request runs `addItem()`. `dispatch()` records the event; nothing is called yet. 2. The response carries the card's new HTML **and** a list of dispatched events. 3. In the browser, Livewire fires each event as a DOM event that bubbles from the dispatching component up to the window. 4. The cart counter, which registered `cart-updated` when it mounted, sends a **follow-up update** to the server with a call to its listener. 5. The counter's `refreshCount()` runs and the counter re-renders. So one user click costs **at least two round trips**: the dispatching component's, then a follow-up in which each listening component is rebuilt, runs its listener and re-renders. That is the price of loose coupling, and it is why events are for cross-component signals, not for work inside one component. ## Narrowing the audience | Form | Who receives it | |---|---| | `$this->dispatch('cart-updated')` | Every listening component on the page | | `$this->dispatch('cart-updated')->to('cart-counter')` | Only the `cart-counter` component (a name or a class) | | `$this->dispatch('cart-updated')->to(component: CartCounter::class)` | Same, with the named argument | | `$this->dispatch('cart-updated')->self()` | Only the component that dispatched it | Targeting prevents unrelated components that happen to use the same event name from reacting, and saves their round trips. ## Other ways to dispatch and listen - **Dynamic names**: `#[On('cart-updated.{cart.id}')]` listens only for the event suffixed with that component's `$cart->id`, useful when many instances are on a page. - **Listening on one child**: `<livewire:cart-line @saved="$refresh" />` in a parent calls the parent's `$refresh` when that child dispatches `saved`; `@saved="recalc($event.detail.lineId)"` forwards data. - **From Blade**: `wire:click="$dispatch('cart-updated')"` and `$dispatchTo('cart-counter', 'cart-updated', { count: 3 })` fire events straight from the browser without a server action first. - **From JavaScript**: because they are browser events, Alpine and plain scripts can listen and dispatch too; that interop is a topic of its own. ## Version note Livewire 2 used `$this->emit()`, `emitTo()` and `emitSelf()` with a `$listeners` array. Livewire 3 replaced them with `dispatch()` and `#[On]`, and Livewire 4 keeps that API. Code or answers using `emit` describe an API that no longer exists. ## When not to use events - To call the parent from a child that always lives in that parent, `$parent.method()` is simpler. - To keep a child in sync with a value the parent owns, a reactive prop is more direct. - For updates that must reach other users or tabs, browser events are not enough; that needs broadcasting, which is a separate system.