@include
Renders another view inside the current one, passing along all of the parent's data.
@include('view.name', ['key' => 'value'])Parameters
| Parameter | Type | Description |
|---|---|---|
$view | string | Dot-notated name of the view to render, relative to the views directory. |
$dataoptional | array= [] | Extra variables merged on top of the parent's data for the included view. |
Return value
Nothing — the rendered output of the child view is emitted in place.
Errors
Including a view that does not exist throws InvalidArgumentException ("View [name] not found."); use @includeIf to tolerate a missing view.
@include renders another Blade file in place. Every variable available to the parent is available to the child, and the optional second argument merges extra data on top.
The variants
@includeIf('view.name')— renders nothing instead of throwing when the view is missing.@includeWhen($bool, 'view.name', [...])and@includeUnless($bool, ...)— conditional include without a wrapping@if.@includeFirst(['custom.admin', 'admin'], [...])— the first view that exists, for themeable overrides.@includeIsolated('view.name', ['user' => $user])— no inherited variables; the child sees only what you pass.@each('view.name', $jobs, 'job', 'view.empty')— a loop and an include in one line. Views rendered this way do not inherit parent variables.
What trips people up
Automatic inheritance is convenient and it is also the coupling that bites: a partial that quietly relies on $user being in scope breaks the day someone includes it from a page that has no $user. Declare what the partial needs by passing it explicitly, or use @includeIsolated. Laravel's own documentation points to components as the better default, since they bind data and attributes deliberately.
Avoid __DIR__ and __FILE__ in views — they resolve to the compiled cache location, not your template.
Example
<?php
// resources/views/orders/show.blade.php
$parent = <<<'BLADE'
<div>
@include('shared.errors')
@include('orders.row', ['highlight' => true])
</div>
BLADE;
// resources/views/orders/row.blade.php
// $order is inherited from the parent; $highlight came from the array above.
$child = <<<'BLADE'
<p>{{ $order->number }}{{ $highlight ? ' *' : '' }}</p>
BLADE;
echo view('orders.show', ['order' => $order])->render();
// <div>
// <p>ORD-1001 *</p>
// </div>When to use it
- Reuse a validation-errors block across every form in the application
- Render one row partial from inside a @foreach over orders
- Include a theme-specific header when it exists and fall back to the default
- Drop an optional analytics snippet with @includeIf so the view is not required
Frequently asked questions
Does an included Blade view inherit the parent's variables?
Yes — @include passes every variable available to the parent, plus any array you supply as the second argument. Use @includeIsolated when you want the child to see only what you pass explicitly.
How do I include a Blade view that might not exist?
Use @includeIf('view.name'), which renders nothing when the view is missing. A plain @include throws an InvalidArgumentException reading "View [name] not found."
Should I use @include or a Blade component?
Laravel's documentation recommends components for new code, because they bind data and attributes explicitly instead of inheriting whatever is in scope. @include remains the lighter option for small fragments that need no contract of their own.
More examples
The conditional and fallback variants
Each variant removes a wrapper that would otherwise appear around a plain @include. @includeFirst is what package publishing relies on: a user-supplied view in the application's own directory silently overrides the packaged one. @includeIsolated is the only variant that changes what the child can see.
<?php
// resources/views/layouts/app.blade.php
$layout = <<<'BLADE'
{{-- Renders nothing if the view is absent --}}
@includeIf('partials.announcement')
{{-- Include only when the flag is true / false --}}
@includeWhen($user->isAdmin(), 'partials.admin-bar', ['status' => 'complete'])
@includeUnless($user->hasVerifiedEmail(), 'partials.verify-notice')
{{-- First view that exists wins --}}
@includeFirst(['custom.admin', 'admin'], ['status' => 'complete'])
{{-- Only $user is in scope inside the child --}}
@includeIsolated('partials.avatar', ['user' => $user])
BLADE;
echo view('layouts.app', ['user' => $user])->render();@each versus @foreach plus @include
@each is shorter and exposes the array key as $key inside the child, but views it renders do not inherit the parent's variables. If jobs/card also needs $currentUser from the page, @each will fail with an undefined variable and the @forelse form is the one to use.
<?php
// One line: renders jobs/card for each item as $job, or jobs/empty when the list is empty.
$each = <<<'BLADE'
@each('jobs.card', $jobs, 'job', 'jobs.empty')
BLADE;
// Equivalent when the child also needs data from the parent scope:
$loop = <<<'BLADE'
@forelse ($jobs as $job)
@include('jobs.card', ['job' => $job])
@empty
@include('jobs.empty')
@endforelse
BLADE;
echo view('jobs.index', ['jobs' => $jobs])->render();Making the partial's inputs explicit
The isolated form documents the partial's contract in the template that uses it, and fails immediately — rather than three pages later — if a required variable is missing. It is the closest @include gets to the explicit data binding a Blade component gives you.
<?php
// Fragile: works only where a $user happens to be in scope.
$implicit = <<<'BLADE'
@include('partials.avatar')
BLADE;
// Robust: the partial's inputs are visible at the call site.
$explicit = <<<'BLADE'
@includeIsolated('partials.avatar', ['user' => $comment->author, 'size' => 32])
BLADE;
echo view('comments.show', ['comment' => $comment])->render();
Discussion