In Laravel Blade, how does a layout component with {{ $slot }} differ from an @extends layout, and which suits a new app?

## Two ways to give a Blade page its shell Almost every page of a web application shares the same outer HTML: the `<head>`, the navigation, the footer. **Blade**, Laravel's template engine, gives you two ways to write that shell once and reuse it: - a **layout component**, which the page *wraps itself in* (composition); - a **layout view with template inheritance**, which the page *extends* (`@extends`, `@section`, `@yield`). Both ship in Laravel 13 and neither is deprecated. The Blade documentation presents components first and describes inheritance as "the primary way of building applications prior to the introduction of components". ## Layout components: composition A layout component is an ordinary Blade component, usually an **anonymous** one stored at `resources/views/components/layout.blade.php`. Its template prints `{{ $slot }}` where the page body belongs: 1. The layout file holds the full HTML document and prints `{{ $slot }}` inside `<body>`. 2. A page wraps its markup in `<x-layout> ... </x-layout>`. 3. Blade captures everything between the tags into the **default slot**, then renders the layout with that slot. Extra regions, such as a page title, travel as component attributes or named slots, and the layout prints them with a fallback such as `{{ $title ?? 'University' }}`. The current Livewire starter kit takes this route: its pages open with `<x-layouts::app :title="...">`. ## Template inheritance: @extends, @section, @yield With inheritance the layout is a plain view, for example `resources/views/layouts/app.blade.php`, containing `@yield('content')` placeholders. The child view: - declares its parent with `@extends('layouts.app')`; - fills named regions with `@section('content') ... @endsection` or the one-line form `@section('title', $course->name)`; - lets the layout print each region with `@yield('name')`, which may take a default as its second argument. The mechanism is worth knowing. The Blade compiler does not print anything where `@extends` appears. It adds a line to the **footer** of the compiled child that calls the view factory's `make()` for the layout, passing the child's `get_defined_vars()`, and renders it. So the child's code runs **first**, stores its sections in the shared view factory, and only then does the layout render and pull those sections back out. ## How the two styles differ | Aspect | Layout component | `@extends` layout | |---|---|---| | Model | composition: page wraps itself in the layout | inheritance: page fills holes in the layout | | Where content goes | `{{ $slot }}` plus named slots | `@yield('name')` for each `@section` | | Data the layout sees | only attributes, slots and `View::share` data | every variable the child view had | | Default for a missing region | `{{ $title ?? '...' }}` or a prop default | `@yield('title', 'Default')` | | Nesting | a section layout wraps itself in `<x-layout>` | a middle layout itself uses `@extends` | | Typical in | Laravel's own docs and the Livewire starter kit | older codebases and many tutorials | The **data-scope** row matters most in practice. An `@extends` layout silently receives every variable the child had, so a layout can come to depend on a variable only some controllers pass. A component layout only receives what it is explicitly given, which keeps its inputs visible at the call site. ## Which to pick For a new Laravel 13 app, prefer **layout components**: - the page reads top to bottom as HTML, with the shell visible as a tag; - the layout's inputs are declared rather than inherited from whatever the child defined; - it is the same mechanism as every other component, so there is one model to learn; - the official Blade starting points already use it. Choose `@extends` when you maintain an app already built on it, or when you want many independent named regions filled from deep inside a child. Rewriting working inheritance layouts purely for style is rarely worth it. ## Mixing them The two styles can live in the same application, even on the same page: a page can `@extends` a layout whose markup uses components, and a component layout can include partials. Stacks (`@push` and `@stack`) work with both, because in both cases the page's own content executes before the layout's markup is printed. ## Mistakes interviewers listen for - Claiming `@extends` is deprecated. It is documented and supported in Laravel 13; it is simply no longer the first style the docs show. - Expecting a layout component to see the page's variables. It does not; pass them as attributes, or share them deliberately. - Believing the layout renders first. With `@extends` the child runs first; with a component the slot is captured first. That order is what makes sections and stacks work. - Mixing the vocabularies: `@section('content')` inside `<x-layout>` does nothing useful, because a component layout never calls `@yield('content')`. - Putting request-specific data, such as the signed-in student's name, into the layout by querying inside it. A layout that runs queries on every page hides cost; supply that data from outside the template instead.