When passing data to a Blade component, what is the difference between type="error", :message="$message" and ::class, and how does @props decide what is a prop?

## Three ways to write an attribute on a component tag A Blade component tag looks like HTML, but Blade reads its attributes as **data**. The prefix decides how: | Syntax | What the component receives | |---|---| | `type="error"` | the string `error` | | `:message="$notice->body"` | the value of the PHP expression | | `:dismissible="true"` | the boolean `true` | | `dismissible="false"` | the string `false`, which is truthy | | `:$roomId` | same as `:room-id="$roomId"` | | `::class="{ open: isOpen }"` | rendered as `:class="{ open: isOpen }"`, not evaluated | Three rules follow: 1. **Plain attributes are strings.** Use them for fixed, author-written values. A number or boolean needs the colon. 2. **Colon attributes are PHP.** The quoted text is an expression evaluated in the parent view, so `:max-guests="$room->capacity"` passes an integer. 3. **Double colon escapes the colon.** Alpine.js and similar libraries use `:attr` for their own bindings. `::` tells Blade to output a literal single-colon attribute instead of evaluating PHP. Attribute names are kebab-case on the tag and camelCase in PHP: `max-guests` reaches the constructor parameter `$maxGuests`, and an anonymous component declaring `'maxGuests'` in `@props`. ## How @props splits props from attributes An anonymous component has no constructor, so it declares its props at the top of the template: ```html @props(['type' => 'info', 'message', 'dismissible' => false]) ``` At render time the compiled `@props` code: - walks the incoming attributes; any key named in the list becomes a local variable (`$type`, `$message`, `$dismissible`); - builds a new `$attributes` bag from the keys that were **not** named; - gives each string-keyed entry its default when the caller did not pass it. An entry without a default (`'message'`) is still a prop - it leaves the bag - but if the caller omits it, echoing `$message` fails as an undefined variable. Give optional props a default, often `null`. On a **class-based** component, the constructor parameters are the props. Blade resolves parameter names from the class and removes them from the bag automatically. ## Escaping: props versus the bag Props arrive as **raw PHP values**. The component must print them with `{{ $message }}`, never `{!! $message !!}` unless it is HTML the component trusts. Values bound with `:` that stay in the **attribute bag** are escaped when the tag compiles, which is why `{{ $attributes }}` is safe to print. ## A hotel-admin modal ```html <x-confirm-modal title="Cancel booking" :booking-id="$booking->id" :refundable="$booking->isRefundable()" ::class="{ 'is-open': open }" class="z-50" /> ``` With `@props(['title', 'bookingId', 'refundable' => false])`, the modal gets a string title, an integer id and a real boolean; `class` and the Alpine binding stay in the bag and land on the root element. ## Checking inputs on a class component A class component gets PHP's own help: typed constructor parameters (`public int $bookingId`, `public bool $refundable = false`) document the interface, defaults live in one place, and a missing required parameter fails when the component is resolved rather than as an undefined variable deep in the template. That is one practical reason to promote a heavily used component from anonymous to class-based. ## Mistakes interviewers look for - Passing `:open="false"`-style booleans without the colon, then wondering why `@if ($open)` is always true. - Writing `:title="Cancel booking"`, which Blade evaluates as PHP and fails to compile. - Using camelCase attributes (`bookingId="..."`) and getting a missing prop. - Forgetting a default for an optional prop and hitting an undefined variable. - Declaring `class` as a prop, which pulls it out of the bag so it is no longer merged.