In nested Blade components such as <x-modal size="lg"> containing <x-modal.footer>, how does @aware let the child read the parent's props, and why can it miss the parent's defaults?

## The problem @aware solves Compound components - a modal with a header, body and footer; a menu with items - often share a setting such as size or colour. The caller sets it once on the outer tag: ```html <x-modal size="lg"> <x-modal.body>...</x-modal.body> <x-modal.footer>...</x-modal.footer> </x-modal> ``` Blade components are **isolated**: `<x-modal.footer>` receives only its own attributes and slots, so it knows nothing about `size`. Passing `size` again to every child is repetitive and error-prone. ## What @aware does In the child template: ```html @aware(['size' => 'md']) <footer {{ $attributes->class(['modal-footer', 'gap-4' => $size === 'lg']) }}> {{ $slot }} </footer> ``` `@aware` compiles to a loop that, for each listed key, calls the view factory's `getConsumableComponentData()`: 1. If the child's own data has the key, use it. 2. Otherwise walk the stack of components currently being rendered, from the nearest parent outwards, and return the first match. 3. If none has it, return the given default (`'md'`). The result is assigned to a local variable (`$size`). Unlike `@props`, `@aware` does not remove anything from the child's attribute bag. ## Why parent defaults are invisible The component data stack holds the data each component was started with. For an **anonymous** parent that is the attributes the caller wrote on its tag. A default declared inside the parent with `@props(['size' => 'lg'])` is applied later, when the parent's own template runs, as a local variable in that template; it is never written back to the stack. (A **class-based** parent is different: its data is its public properties, so a constructor default such as `public string $size = 'lg'` is visible to `@aware`.) So: | Caller writes | Modal's `$size` | Footer's `@aware` `$size` | |---|---|---| | `<x-modal size="lg">` | `lg` | `lg` | | `<x-modal size="sm">` | `sm` | `sm` | | `<x-modal>` (modal default `lg`) | `lg` | **`md`** - its own default | The last row is the classic bug: the modal renders large while its footer renders medium spacing. The Laravel docs call this out explicitly: `@aware` cannot access parent data that was not explicitly passed to the parent via HTML attributes. ## Fixes - **Mirror the default.** Use the same default in the parent's `@props` and every child's `@aware`. Simple, but two places to keep in sync. - **Centralise the default.** Read it from one PHP constant or config value in both places. - **Pass it explicitly** where it matters, accepting a little repetition. - **Make the parent a class component.** Its public properties, constructor defaults included, are part of the data `@aware` reads. ## When @aware is the right tool - Shared visual settings in compound components: size, tone, density, colour. - Values the caller normally sets on the outer tag. It is a poor fit for business data (the booking being cancelled) - pass that explicitly, so the child's inputs stay visible at the call site - and for deep, far-apart nesting where a reader cannot tell which ancestor supplies the value. ## @aware compared with @props | | `@props` | `@aware` | |---|---|---| | Reads from | the component's own tag | enclosing components' data | | Removes the key from `$attributes` | yes | no | | Default applies when | the caller omits the attribute | no ancestor passed it | | Typical use | the component's interface | settings shared down a compound component | A child can list the same name in both, so it accepts `size` directly but falls back to its parent's value. ## Testing it Render the parent with and without the attribute and assert on the child's output, for example with `Blade::render('<x-modal><x-modal.footer>ok</x-modal.footer></x-modal>')`. The no-attribute case is the one that exposes mismatched defaults.