Laravel Blade Components: A Practical Guide

A Blade component packages a reusable chunk of markup — and optionally, backing logic — into something you can drop into any view with its own props, rather than repeating the same HTML structure across many templates.

Creating an anonymous component (markup only, no class)

php artisan make:component alert --view

{{-- resources/views/components/alert.blade.php --}}
@props(['type' => 'info'])


    {{ $slot }}

    Something went wrong.

An anonymous component is just a Blade file with no accompanying PHP class — appropriate when the component is pure markup with simple prop-based variation, and no real logic needed behind it.

Creating a class-based component (when you need real logic)

php artisan make:component OrderSummary

class OrderSummary extends Component
{
    public $order;
    public $total;

    public function __construct(Order $order)
    {
        $this->order = $order;
        $this->total = $order->items->sum(fn ($item) => $item->price * $item->quantity);
    }

    public function render()
    {
        return view('components.order-summary');
    }
}

{{-- resources/views/components/order-summary.blade.php --}}

    
Order #{{ $order->id }}
    
Total: ${{ number_format($total, 2) }}

A class-based component is the right choice once the component needs actual computation, dependency injection, or logic beyond what's reasonable to express directly in a Blade template — the constructor here calculates the total once, rather than repeating that calculation logic inline in the view.

Named slots, for a component with multiple distinct content areas

{{-- components/card.blade.php --}}

    
{{ $header }}
    
{{ $slot }}

    
        Card Title
    

    This is the main card content.

Passing PHP expressions as props, not just static strings

The colon prefix (:order rather than order) tells Blade to evaluate the attribute as a PHP expression rather than treating it as a literal string — necessary any time you're passing a variable, an object, or an expression rather than plain static text.

When to reach for a component vs. a plain @include

An @include is a simple, direct template inclusion sharing the including view's variable scope — a component is the better choice once you need a clearly-defined prop interface (rather than relying on whatever variables happen to be in scope), reusable logic behind the markup, or named slots for multiple distinct content areas within the same reusable piece.