In Livewire 4, when a user edits the quantity of one row in a public $items array, which update hooks fire and with what arguments?

## How Livewire addresses nested data A **public array property** such as `$items` on an order form can hold a list of lines, each with `sku`, `quantity` and `unitPrice`. The browser does not resend the whole array when one field changes; it sends an update for a **dotted path**, for example `items.2.quantity`. Livewire calls the `updating*` hooks, walks that path and writes the leaf value, and later calls the `updated*` hooks. Knowing what each hook receives is what lets one method recompute the right line. ## Which hooks fire for items.2.quantity | Hook | Called with | |---|---| | `updating($property, $value)` | `'items.2.quantity'`, new value | | `updatingItems($value, $key)` | new value, `'2.quantity'` | | `updated($property, $value)` | `'items.2.quantity'`, new value | | `updatedItems($value, $key)` | new value, `'2.quantity'` | So the property-level hook's `$key` is **everything after the first dot**. A typical order-form handler splits it: ```php public function updatedItems($value, ?string $key): void { if ($key === null) { $this->recalculateAll(); return; } [$row, $field] = explode('.', $key, 2) + [1 => null]; if ($field === 'quantity') { $this->recalculateLine((int) $row); } } ``` ## Nested-name hooks Livewire also tries a method built from the **whole path**: the dots become underscores and the result is StudlyCased, so a path `bar.baz` looks for `updatedBarBaz($value, $key)`. For that hook `$key` is the segment after the **last** dot. It is a niche feature; for list data with numeric indexes the property-level hook with its `$key` argument is the readable choice. ## When $key is null If the whole array is written at once, there is no sub-path, so the property-level hooks receive the complete new array as `$value` and `null` as `$key`. A handler must therefore treat `null` as "everything may have changed". ## What changed in Livewire 4 In **Livewire 3**, replacing a whole array from JavaScript (for example setting `$wire.items` to a new list) produced a series of granular updates, one per changed index plus special removal markers, so `updatedItems()` could fire several times for one user action. **Livewire 4** sends one consolidated update instead, so the hooks fire **once** with the full array. Editing a single row still sends a single-path update, so the per-row behaviour above is unchanged. Code that counted on per-index hook calls when a whole array is swapped needs to handle the `null`-key case. ## Timing inside the request - Each `updating*` hook fires as its own value is written, while the property still holds the old data. - All `updated*` hooks fire after **every** update in the request has been written, so a handler can read sibling fields that changed in the same request. - The action (if any) runs after that, then the view renders. ## Pitfalls interviewers look for 1. Assuming `$key` is the row index alone; it is the whole remaining path, `'2.quantity'`. 2. Forgetting the `null` key when the array is replaced wholesale. 3. Trusting the index: a user can send any path, so re-check that the row exists before using it. 4. Writing heavy per-row work in `updated()` without filtering on the path, which then runs for every property on the component. ## A readable pattern for list data For an order form with many lines, a clean structure is: 1. one `updatedItems($value, $key)` handler that splits `$key` into row and field; 2. a guard that the row exists and the field is one the user may edit; 3. a single `recalculateLine($row)` or `recalculateAll()` method that both the hook and any action call. This keeps the argument parsing in one place and makes the `null`-key case explicit. When the list grows large or each line gains its own behaviour, moving each line into its own child component gives every line its own simple, non-array update hooks; that decision belongs to how the component is structured rather than to the hooks themselves.