In Livewire, when does an input bound with wire:model send its value to the server, and what does the .live modifier change?
answer
- deferred until the next action
- no request while typing
- .live sends updates as you type
- 150 ms debounce on text inputs
- wire:model.defer is Livewire 2
basics
~20 sBy default wire:model is deferred: typing updates only client-side state, and the value reaches the server with the next action's request, such as a wire:submit. wire:model.live sends an update as the value changes, debounced 150 ms on text inputs.
solid answer
~30 s`wire:model="search"` binds an input to the public `$search` property, but it is **deferred**: typing updates the component's client-side state only, and the change travels to the server with the **next request** the component makes, typically `wire:click` or `wire:submit`. That keeps forms cheap: no request per keystroke. `wire:model.live="search"` sends an update request as the value changes, which you need for search-as-you-type or real-time validation; on text inputs and textareas it is debounced by **150 ms** by default, and `.live.debounce.300ms` or `.live.throttle.500ms` tune that. Checkboxes, radios and selects send immediately. Deferred is the default since Livewire 3; Livewire 2's `wire:model.defer` no longer exists.
code
html · 8 lines<form wire:submit="applyFilters">
<input type="text" wire:model.live.debounce.300ms="search">
<input type="number" wire:model="minPrice">
<input type="number" wire:model="maxPrice">
<button type="submit">Apply price range</button>
</form>go deeper
Recall that wire:model is deferred until the next action and that .live sends updates as the user types.
Explain how pending updates ride on the next request, the 150 ms debounce on text inputs, and debounce versus throttle after .live.
Choose binding timing per field to balance feedback against request volume, and spot Livewire 2 idioms like .defer in upgrades.
Set form conventions on live versus deferred fields, weighing server load from per-keystroke renders against perceived responsiveness.
## Two-way binding with wire:model `wire:model` links a form control to a **public property** of a Livewire component. The value flows both ways: the property's value fills the input when the component renders, and what the user types is written back to the property. The question is **when** the server hears about it. ## The default: deferred binding With plain `wire:model`, Livewire updates the component's **client-side** copy of the property as the user types, but sends **no request**. The pending change is sent along with the **next request** the component makes for any reason: - a `wire:submit` or `wire:click` action, - a `$refresh` or `$set`, - a live update from another bound field. On the server, Livewire first applies all pending property updates, then runs the action. So in a product search form, `save()` or `search()` sees every field the user filled in, even though none of them caused a request on its own. This default exists to cut network traffic: a ten-field form costs one request on submit instead of hundreds while typing. ## .live: send as the value changes ```html <input type="text" wire:model.live="search" placeholder="Search products"> ``` With `.live`, every change triggers an update request, and the component re-renders with the new state, for example a filtered product list. | Binding | Request sent | Typical use | |---|---|---| | `wire:model` | With the next action or other request | Ordinary forms submitted with a button | | `wire:model.live` | On change, 150 ms debounce on text inputs | Search-as-you-type, dependent selects | | `wire:model.live.debounce.400ms` | After 400 ms without typing | Expensive searches | | `wire:model.live.throttle.500ms` | At most every 500 ms while typing | Continuous feedback during long input | Details that matter: 1. The **150 ms debounce** applies to text-like inputs and textareas. Checkboxes, radio buttons and selects send immediately. 2. `.debounce` and `.throttle` are placed **after** `.live`; they control network timing. 3. In Livewire 4, overlapping `.live` updates can run in parallel, and a response for an older update is discarded once a newer one has landed. ## Version history you will be asked about | Version | Default | Explicit modifiers | |---|---|---| | Livewire 2 | Live (every input sent) | `wire:model.defer`, `wire:model.lazy` | | Livewire 3 | Deferred | `wire:model.live`, `.blur`, `.change` | | Livewire 4 | Deferred | `.live`, plus `.blur` and `.change` now also delay the client-side sync | `wire:model.defer` was removed because deferring became the default. Code that still uses it is Livewire 2 code. ## Common mistakes - Expecting a deferred field to update a filtered list as the user types; nothing is sent until an action runs. - Adding `.live` to every field of a long form, multiplying requests and server renders. - Putting a debounce before `.live` (`wire:model.debounce.300ms.live`): modifiers before `.live` control client-side sync, not the request. - Printing the value inside the input (`<textarea wire:model="notes">{{ $notes }}</textarea>`); Livewire fills bound controls itself. ## A product search example A product search has a text query and a price range. The query uses `.live` with a slightly longer debounce so the list filters as the user types; the price inputs stay deferred or sync on blur, and an "Apply" button submits them. The user sees fast feedback where it matters without a request for every digit typed into a price.
- In Livewire, a deferred wire:model field and a wire:click button are on the same component; in what order does the server apply them?The click's request carries the pending property updates and the action call. Livewire applies the property updates first, including any validation or update hooks, and then calls the action, so the action sees the values the user typed.
- What replaced Livewire 2's wire:model.defer in Livewire 3 and 4?Nothing needs to replace it: plain `wire:model` is deferred by default since Livewire 3, so `.defer` was removed. The explicit modifier now goes the other way: `.live` opts a field into sending updates as it changes.
- Why do checkboxes bound with wire:model.live send immediately while text inputs wait?Livewire applies its default 150 ms debounce only to text-like inputs and textareas, where each keystroke fires an event. A checkbox, radio or select changes once per user action, so debouncing would only add delay.
saying these in an interview costs you the question
- wire:model sends a request on every keystroke by default
- You need wire:model.defer in Livewire 4 to avoid requests while typing
- Deferred values are lost unless the field uses .live
- .live sends a request instantly on every keystroke with no debounce
- Modifiers written before .live control when the request is sent