Laravel Blade Templates: Tips and Tricks
Most Laravel projects start with tidy views. A year later you open dashboard.blade.php and find 400 lines of nested @if blocks, the same navbar query copied into five controllers, and a <script> tag that loads twice because two partials both include it. Blade had answers for all of that the whole time. Most of us just never got past @if, @foreach and @extends.
This post covers the parts of Blade I reach for once a project grows: how compilation works, the less obvious directives, components and slots, layouts, custom directives, stacks, view composers, and a few gotchas that show up in production.
Blade compiles templates to plain PHP and caches the result until the source file changes. After the first request, you're running ordinary PHP, so the templating layer adds essentially no runtime overhead. And unlike Twig, you can still drop into plain PHP when you need to.
How Blade Works Under the Hood
Knowing what Blade does with your template makes a lot of weird bugs easier to track down. The first time a view is requested, Laravel compiles it into a PHP file in storage/framework/views/. On later requests it compares the source file's modification time with the compiled one. If nothing changed, it runs the cached version directly.
Blade's compile-and-cache pipeline
A few practical consequences:
- Blade itself is cheap. Once compiled, a template runs like any other PHP file. Slow views are almost always slow because of queries, not directives.
- Cache invalidation is automatic. Edit the template and Blade recompiles it on the next request.
- You can read the compiled output in
storage/framework/views/when a directive does something you didn't expect. - In production, run
php artisan view:cacheduring deploy so the first visitor doesn't pay the compile cost.
When a view throws, the stack trace sometimes shows a path like storage/framework/views/3f9a...c1.php instead of your Blade file. Open that file and look at the top: recent Laravel versions add a /**PATH ... ENDPATH**/ comment that tells you which template it came from. Also, if you deploy by copying files with preserved timestamps, an old compiled view can outlive the new template. Running php artisan view:clear after deploy rules that out.
Directives Beyond @if and @foreach
Everyone knows @if and @foreach. These are the built-in directives I see skipped most often, even though they remove a lot of noise from templates.
These read better than wrapping everything in @if:
{{-- @isset / @empty --}}
@isset($user)
<p>User: {{ $user->name }}</p>
@endisset
@empty($items)
<p>No items found.</p>
@endempty
{{-- @unless (inverse of @if) --}}
@unless(auth()->check())
<a href="/login">Please log in</a>
@endunless
{{-- @switch / @case --}}
@switch($status)
@case('active')
<span class="badge green">Active</span>
@break
@case('pending')
<span class="badge yellow">Pending</span>
@break
@default
<span class="badge gray">Inactive</span>
@endswitch
{{-- Null coalescing with ternary --}}
{{ $user->bio ?? 'No bio provided.' }}
{{ $user->role === 'admin' ? 'Administrator' : 'Member' }}The $loop variable gives you metadata about the current iteration:
@foreach($posts as $post)
<article class="{{ $loop->odd ? 'bg-gray' : '' }}">
{{-- $loop->index → 0-based index --}}
{{-- $loop->iteration → 1-based count --}}
{{-- $loop->first → true on first item --}}
{{-- $loop->last → true on last item --}}
{{-- $loop->count → total items --}}
{{-- $loop->remaining → items left --}}
{{-- $loop->depth → nesting depth --}}
{{-- $loop->parent → parent $loop in nested loops --}}
@if($loop->first)
<div class="featured-badge">Featured</div>
@endif
<h2>{{ $loop->iteration }}. {{ $post->title }}</h2>
@if($loop->last)
<hr><p>End of posts</p>
@endif
</article>
@endforeach
{{-- Nested loop with $loop->parent --}}
@foreach($categories as $category)
@foreach($category->posts as $post)
@if($loop->parent->first)
<h3>{{ $category->name }}</h3>
@endif
<p>{{ $post->title }}</p>
@endforeach
@endforeachControl visibility based on authentication state and roles:
{{-- Simple auth/guest check --}}
@auth
<a href="/dashboard">Dashboard</a>
@endauth
@guest
<a href="/login">Login</a>
@endguest
{{-- Specify a guard --}}
@auth('admin')
<a href="/admin">Admin Panel</a>
@endauth
{{-- @can / @cannot (Gates and Policies) --}}
@can('edit', $post)
<a href="/posts/{{ $post->id }}/edit">Edit</a>
@endcan
@cannot('delete', $post)
<span class="disabled">Delete not available</span>
@endcannot
{{-- @canany -- matches if user can do any of the listed abilities --}}
@canany(['update', 'delete'], $post)
<div class="post-actions">...</div>
@endcananyConditionally render content based on the application environment:
{{-- @env checks APP_ENV --}}
@env('local')
<div class="debug-bar">
Debug mode is active
</div>
@endenv
@env(['staging', 'production'])
<!-- Analytics script -->
<script src="analytics.js"></script>
@endenv
{{-- @production is a shorthand --}}
@production
<script>
// Only runs in production
initErrorTracking();
</script>
@endproduction
{{-- Useful for toggling debug tools --}}
@env('local')
@include('partials.debugbar')
@endenvBlade Components and Slots
If you're still building reusable UI with @include and a pile of passed variables, components are worth the switch. Since Laravel 7 you can write class-based or anonymous components and use them with HTML-like <x-alert> tags. They replace the older @component / @slot syntax, and props, slots and attributes all have a clear place to live.
Creating a Component
Generate the component
Run php artisan make:component Alert. This creates app/View/Components/Alert.php and resources/views/components/alert.blade.php.
Define props in the class
Use the $props array or constructor injection to declare the component's public API.
Use the component in Blade
Reference it with the <x-component-name> tag syntax anywhere in your views.
<?php
namespace App\View\Components;
use Illuminate\View\Component;
class Alert extends Component
{
public function __construct(
public string $type = 'info',
public string $title = ''
) {}
public function render()
{
return view('components.alert');
}
// Computed property available in the template
public function iconClass(): string
{
return match($this->type) {
'success' => 'fas fa-check-circle text-green-500',
'warning' => 'fas fa-exclamation-triangle text-yellow-500',
'error' => 'fas fa-times-circle text-red-500',
default => 'fas fa-info-circle text-blue-500',
};
}
}<div class="alert alert-{{ $type }}" role="alert">
<div class="alert-header">
<i class="{{ $iconClass() }}"></i>
@if($title)
<strong>{{ $title }}</strong>
@endif
</div>
{{-- $slot contains whatever is placed between the tags --}}
<div class="alert-body">
{{ $slot }}
</div>
{{-- Named slot for optional action buttons --}}
@if($actions->isNotEmpty())
<div class="alert-actions">
{{ $actions }}
</div>
@endif
</div>{{-- Basic usage --}}
<x-alert type="success" title="Payment confirmed">
Your order #1234 has been placed successfully.
</x-alert>
{{-- With named slot --}}
<x-alert type="warning" title="Account expiring">
Your free trial ends in 3 days.
<x-slot:actions>
<a href="/billing" class="btn btn-sm">Upgrade now</a>
</x-slot:actions>
</x-alert>
{{-- Passing dynamic data --}}
<x-alert :type="$notificationType" :title="$notificationTitle">
{{ $notificationMessage }}
</x-alert>For simple components that don't need a PHP class, create only the Blade file in resources/views/components/ and declare props at the top with @props(['type' => 'info', 'title' => '']). No class file needed.
The alert template above calls $actions->isNotEmpty(). If someone uses <x-alert> without an actions slot, that variable was never defined and you get Undefined variable $actions. Guard it with @isset($actions), or in an anonymous component give it a default with @props(['actions' => null]) and check for null.
Template Inheritance and Layouts
You have two ways to build layouts: the classic @extends/@section pattern and component-based layouts. Both work fine. Mixing them randomly across one project is what gets confusing, so pick one as the default.
| Feature | @extends / @section | Component Layouts |
|---|---|---|
| Laravel version | All versions | Laravel 7+ |
| Syntax | @extends('layouts.app') |
<x-app-layout> |
| Multiple sections | Yes, via named @yield |
Yes, via named slots |
| Composability | Single inheritance only | Freely nestable |
| Best for | Traditional MVC pages | Component-driven UIs |
<!DOCTYPE html>
<html lang="{{ str_replace('_', '-', app()->getLocale()) }}">
<head>
<meta charset="UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<title>{{ $title ?? config('app.name') }}</title>
@vite(['resources/css/app.css', 'resources/js/app.js'])
{{ $head ?? '' }}
</head>
<body class="antialiased">
@include('partials.navbar')
<main>
{{ $slot }}
</main>
@include('partials.footer')
{{ $scripts ?? '' }}
</body>
</html><x-app-layout>
<x-slot:title>Dashboard - {{ config('app.name') }}</x-slot:title>
<x-slot:head>
<!-- Page-specific meta or styles -->
<link rel="stylesheet" href="/css/dashboard.css">
</x-slot:head>
<!-- Main page content goes here -->
<div class="container">
<h1>Welcome back, {{ auth()->user()->name }}!</h1>
@include('dashboard.stats')
</div>
<x-slot:scripts>
<script src="/js/dashboard.js"></script>
</x-slot:scripts>
</x-app-layout>Custom Blade Directives
When you keep writing the same @if condition or formatting call across templates, register a custom directive in a service provider. They compile to PHP just like the built-in ones, so they cost nothing extra at runtime. One thing to keep in mind: Blade::directive() receives the raw expression as a string, not its value, so you're generating PHP code, not calling a function.
<?php
namespace App\Providers;
use Illuminate\Support\ServiceProvider;
use Illuminate\Support\Facades\Blade;
class AppServiceProvider extends ServiceProvider
{
public function boot(): void
{
// Simple output directive
Blade::directive('datetime', function ($expression) {
return "<?php echo ($expression)->format('M d, Y H:i'); ?>";
});
// Conditional directive pair
Blade::directive('role', function ($expression) {
return "<?php if(auth()->check() && auth()->user()->hasRole($expression)): ?>";
});
Blade::directive('endrole', function () {
return "<?php endif; ?>";
});
// If directive
Blade::if('subscribed', function () {
return auth()->check() && auth()->user()->subscribed();
});
}
}{{-- @datetime directive --}}
<time>Published: @datetime($post->published_at)</time>
{{-- Outputs: Published: Jan 15, 2026 09:30 --}}
{{-- @role / @endrole directive --}}
@role('editor')
<a href="/posts/create">New Post</a>
@endrole
@role('admin')
<a href="/admin">Admin Panel</a>
@endrole
{{-- Blade::if() custom directive --}}
@subscribed
<div class="premium-content">
Exclusive content for subscribers...
</div>
@elsesubscribed
<a href="/subscribe">Subscribe to unlock</a>
@endsubscribedAfter registering new custom directives, run php artisan view:clear to force Blade to recompile templates. Existing cached files won't pick up the new directive unless cleared.
Tips, Tricks, and Best Practices
Small habits, but they're what keep views readable a year in.
1. Use @include with data binding
{{-- Pass data explicitly so the partial's inputs are obvious --}}
@include('partials.user-card', ['user' => $author, 'showBio' => true])
{{-- @includeIf: silently skips if the file doesn't exist --}}
@includeIf('partials.promo-banner', ['campaign' => $campaign])
{{-- @includeWhen: conditional include, no @if boilerplate needed --}}
@includeWhen($user->isAdmin(), 'partials.admin-tools')
{{-- @includeUnless: inverse conditional --}}
@includeUnless($user->hasDismissed('banner'), 'partials.welcome-banner')
{{-- @includeFirst: tries multiple views, uses the first that exists --}}
@includeFirst(['themes.custom.header', 'partials.default-header'])2. @stack and @push for asset injection
Stacks don't get used nearly enough. A child view can push scripts or styles into a named spot in the layout, so a chart library only loads on the one page that draws a chart instead of on every page.
<head>
<!-- Global styles -->
@vite('resources/css/app.css')
{{-- Child views can push page-specific styles here --}}
@stack('styles')
</head>
<body>
{{ $slot }}
<!-- Global scripts -->
@vite('resources/js/app.js')
{{-- Child views can push page-specific scripts here --}}
@stack('scripts')
</body>@push('styles')
<link rel="stylesheet" href="/css/chart.css">
@endpush
<x-app-layout>
<div id="chart-container"></div>
</x-app-layout>
@push('scripts')
<script src="https://cdn.jsdelivr.net/npm/chart.js"></script>
<script>
new Chart(document.getElementById('chart-container'), { ... });
</script>
@endpush
{{-- @prepend inserts at the TOP of the stack instead of appending --}}
@prepend('scripts')
<script>window.userId = {{ auth()->id() }}</script>
@endprepend3. @once for one-time rendering
{{-- This component might be included 50 times on a page --}}
@foreach($products as $product)
<x-product-card :product="$product" />
@endforeach
{{-- Inside components/product-card.blade.php --}}
@once
@push('scripts')
{{-- This script is only pushed once, not 50 times --}}
<script src="/js/product-card.js"></script>
@endpush
@endonce
<div class="product-card">
...
</div>4. Inline Blade compilation
use Illuminate\Support\Facades\Blade;
// Useful for user-defined templates stored in the database
$template = 'Hello, {{ $name }}! You have {{ $count }} notifications.';
$rendered = Blade::render($template, [
'name' => $user->name,
'count' => $user->unread_notifications->count(),
]);
echo $rendered;
// → Hello, Jane! You have 3 notifications.Advanced Techniques
Service Injection
@inject pulls a service straight out of the container into the template. It's handy for settings or feature flags you don't want to thread through every controller. I use it sparingly, though: a view that calls services is harder to test and easier to turn into a hidden source of queries.
@inject('settings', 'App\Services\SettingsService')
@inject('metrics', 'App\Services\MetricsService')
<div class="sidebar">
@if($settings->get('show_analytics'))
<div class="analytics-widget">
<span>Visitors today: {{ $metrics->todayVisitors() }}</span>
</div>
@endif
<p>App version: {{ $settings->get('app_version') }}</p>
</div>View Composers and Shared Data
If every controller passes the same cart count or notification badge, move it into a view composer. You can attach data to one view, a wildcard group, or every view. Watch out with View::share() in a service provider: it runs on every request, including console commands and queue workers, so a database call there can break php artisan migrate on a fresh database.
public function boot(): void
{
// Share with a specific view
View::composer('partials.navbar', function ($view) {
$view->with('cartCount', auth()->check()
? auth()->user()->cart()->count()
: 0
);
});
// Share with a group of views using wildcards
View::composer('admin.*', function ($view) {
$view->with('pendingApprovals', Post::where('status', 'pending')->count());
});
// Share globally with all views
View::share('siteConfig', SiteConfig::get());
}Deferring Component Rendering
Livewire 3 has lazy components built in, but you don't need Livewire for this. In plain Blade you can render a placeholder, expose the heavy partial on its own route, and fetch it with a few lines of JavaScript (or Alpine).
{{-- In your blade view --}}
<div
id="heavy-chart"
data-src="/partials/revenue-chart"
class="lazy-partial"
>
<div class="skeleton-loader">Loading chart...</div>
</div>
@push('scripts')
<script>
document.querySelectorAll('.lazy-partial').forEach(el => {
fetch(el.dataset.src)
.then(r => r.text())
.then(html => el.outerHTML = html);
});
</script>
@endpushComplete Blade Directives Reference
| Directive | Purpose |
|---|---|
@yield('name') | Render a named section in the layout |
@section / @endsection | Define a content section |
@parent | Include parent section content |
@stack / @push | Push content into named stacks |
@once | Render block only once per page |
@verbatim | Output raw text without Blade parsing |
@php / @endphp | Execute raw PHP inline |
@inject('var', 'Class') | Inject a service into the view |
@json($array) | Output JSON-encoded value (XSS-safe) |
@class(['a' => true]) | Conditional class attribute builder |
@style(['a' => true]) | Conditional style attribute builder |
@checked($bool) | Output "checked" if true |
@selected($bool) | Output "selected" if true |
@disabled($bool) | Output "disabled" if true |
@required($bool) | Output "required" if true |
@readonly($bool) | Output "readonly" if true |
Blade Mistakes I See Most Often
Blade is easy to start with, and that's exactly why views drift into a mess. These are the problems that come up again and again in code review:
What to watch for
- Queries inside loops.
{{ $post->author->name }}in a@foreachfires one query per row unless the controller eager loads withwith('author'). Blade hides N+1 problems very well. - Using
{!! !!}on user input. It skips escaping. Only use it for HTML you generated or sanitized yourself. - Custom directives for everything. They're compiled, so they're hard to debug and need a
view:clearevery time you change them. If a helper function or a component does the job, I'd use that instead. - Business logic in
@phpblocks. If a view needs ten lines of PHP to prepare data, that code belongs in the controller, a view model, or the component class. - Components for one-off markup. A component used exactly once just adds a file to jump to. Plain HTML, or an
@include, is fine until there's a second use. - Forgetting
view:cacheon deploy. Not a disaster, but the first requests after each deploy pay the compile cost for every view they touch.
And when not to lean on Blade at all: if a page is mostly client-side state (drag and drop builders, live dashboards, complex forms with lots of interdependent fields), you'll end up fighting server-rendered templates. That's where Livewire, Inertia with Vue or React, or a separate frontend makes more sense. For everything else, plain Blade with components and a few stacks covers a lot more ground than people expect.