Arr::undot
Expands an array of dot-notation keys back into a nested multi-dimensional array.
public static function undot($array)- Added in Laravel 8.x
Parameters
| Parameter | Type | Description |
|---|---|---|
$$array | iterable | A single-level iterable whose keys use dot notation to express depth. |
Return value
arrayA multi-dimensional array built by expanding each dotted key into nested levels.
Arr::undot is the inverse of Arr::dot. It walks the array once and calls Arr::set for every entry, so each dotted key is expanded into the nesting it describes and the intermediate arrays are created on the way down.
When to reach for it
It is the natural landing point for anything that arrives as flat key paths: a settings table with one row per dotted key, an .env-style or INI-style import, a form whose inputs are named address.city, or the output of a job that produced dotted keys and now needs to be handed to something expecting a tree.
What trips people up
Expansion is destructive when keys collide. Because Arr::set replaces any non-array value standing in the way of a deeper path, an input of ['a' => 1, 'a.b' => 2] quietly throws away the scalar and leaves ['a' => ['b' => 2]]. Order matters too: process the keys in a different order and you get a different winner. Numeric segments become integer keys, so items.0.sku rebuilds a real list, and a key that legitimately contains a dot cannot survive the trip.
Example
When to use it
- Rebuilding a config tree from a settings table stored as one row per dotted key.
- Turning a form request whose inputs are named address.city into nested data.
- Restoring a nested payload that was flattened for storage or transport.
Frequently asked questions
Is Arr::undot the opposite of Arr::dot?
Yes, it expands dotted keys back into nested arrays. The round trip is lossless as long as none of the original keys contained a literal dot.
Why did Arr::undot lose one of my values?
Two keys collided: a scalar and a deeper path cannot both occupy the same slot, so the later write replaces the earlier one. Whether the scalar or the nested array survives depends purely on key order.
Does Arr::undot produce lists or objects for numeric keys?
Numeric segments become integer array keys, so items.0 and items.1 rebuild a genuine PHP list that json_encode renders as a JSON array.
More examples
A settings table to a config tree
Prints {"billing":{"currency":"EUR","vat":{"rate":21}},"branding":{"logo":"logo.svg"}}. array_column turns the rows into a dotted key/value map and undot expands it into the tree the rest of the application expects, creating the intermediate billing and vat arrays automatically.
<?php
use Illuminate\Support\Arr;
$rows = [
['key' => 'billing.currency', 'value' => 'EUR'],
['key' => 'billing.vat.rate', 'value' => 21],
['key' => 'branding.logo', 'value' => 'logo.svg'],
];
$settings = Arr::undot(array_column($rows, 'value', 'key'));
echo json_encode($settings), "\n";Nesting flat form input
Prints {"name":"Ada","address":{"line1":"10 Main St","city":"Lisbon"}} then Lisbon. Keys without a dot are copied across unchanged, so a mixed payload of flat and dotted keys expands correctly in one pass.
<?php
use Illuminate\Support\Arr;
$input = [
'name' => 'Ada',
'address.line1' => '10 Main St',
'address.city' => 'Lisbon',
];
$data = Arr::undot($input);
echo json_encode($data), "\n";
echo $data['address']['city'], "\n";Order decides the winner on a collision
Prints {"a":{"b":2}} then {"a":1}. In the first case the scalar is replaced by the array needed for the deeper path; in the second the scalar is written last and destroys the array. Neither raises an error, so validate your key set before expanding data you did not produce.
<?php
use Illuminate\Support\Arr;
echo json_encode(Arr::undot(['a' => 1, 'a.b' => 2])), "\n";
echo json_encode(Arr::undot(['a.b' => 2, 'a' => 1])), "\n";
Discussion