skip to content

Data Binding & Forms

2 roadmaps5 questions

wire:model syncs inputs to public properties, deferred until the next action unless .live says otherwise, and Form objects group fields with #[Validate] rules. Interviewers probe update timing.

on this pageshow

explore

questions

5

In Livewire, when does an input bound with wire:model send its value to the server, and what does the .live modifier change?

level: juniorimportance: must knowfreq 70%

answer

  1. deferred until the next action
  2. no request while typing
  3. .live sends updates as you type
  4. 150 ms debounce on text inputs
  5. wire:model.defer is Livewire 2

basics

~20 s

By 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
html
<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

for a junior

Recall that wire:model is deferred until the next action and that .live sends updates as the user types.

for a middle

Explain how pending updates ride on the next request, the 150 ms debounce on text inputs, and debounce versus throttle after .live.

for a senior

Choose binding timing per field to balance feedback against request volume, and spot Livewire 2 idioms like .defer in upgrades.

for a principal

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
open as a page

In a Livewire component, how do #[Validate] attributes and $this->validate() work together, and how does real-time validation happen?

level: middleimportance: must knowfreq 55%

basics

~20 s

#[Validate('required|numeric')] on a Livewire public property registers its rules and validates that property whenever an update for it reaches the server, so .live or .live.blur bindings give real-time errors. $this->validate() checks every rule before saving and throws on failure.

open as a page

In Livewire 4, how do the wire:model modifiers .blur, .change, .enter and .deep behave, and why does .live.blur differ from .blur.live?

level: middleimportance: should knowfreq 42%

basics

~20 s

In Livewire 4, modifiers before .live set when client-side state syncs; modifiers after .live set when the request is sent. .blur.live syncs and sends on blur; .live.blur syncs per keystroke, sends on blur. .deep hears child events again.

open as a page

In Livewire, what is a Form object created with php artisan livewire:form, and how do you bind, validate and reset its fields?

level: middleimportance: should knowfreq 40%

basics

~20 s

A Livewire Form object is a class extending Livewire\Form (livewire:form writes it to app/Livewire/Forms) that holds a form's fields, #[Validate] rules and save logic. A component declares public FilterForm $form; inputs bind to form.field, and $this->form->validate() and reset() act on the form.

open as a page

A Livewire product search binds its query and price-range inputs with wire:model.live and hammers the server while showing flickering results; how would you tune the bindings?

level: seniorimportance: should knowfreq 30%

basics

~20 s

Give each Livewire field the timing it needs: debounce the query (wire:model.live.debounce.400ms), send price inputs on blur or Enter, keep rarely used filters deferred behind an Apply button, and show wire:dirty or loading states so users know input is pending.

open as a page