Statamic Blade Components Laravel Package

Getting Started

The package lets Antlers templates render Laravel Blade components, so you can keep your "view partial" logic in Blade (component classes, slots, service injection) while authoring pages in Antlers. The typical starting point is a small reusable UI piece — an alert, button, card, or badge — that you already use in your Laravel views.

1. Install it in the Statamic project:

   composer require octoper/statamic-blade-components
   

2. Publish any provided config (check the package README and src/ServiceProvider for the publish tag — most Octoper packages expose one):

   php artisan vendor:publish --provider="Octoper\StatamicBladeComponents\ServiceProvider"
   

3. First place to look: the config/statamic-blade-components.php file (if published) and the package's src/ directory. The ServiceProvider shows how the Antlers tag is registered; the config usually lets you tweak the tag name or component namespace.

4. Your first use case — drop a component into an Antlers template:

   {{ blade:alert type="success" }}
       Your entry was saved.
   {{ /blade:alert }}
   

   The Blade component behind it is a normal class-based component (app/View/Components/Alert.php with resources/views/components/alert.blade.php). If you can render it with <x-alert> in Blade, you can usually render it with the Antlers tag.

5. Sanity check by rendering the same component in a Blade view (<x-alert type="success">Saved</x-alert>) and in Antlers — if they match, your setup is correct.

Implementation Patterns

Static vs. dynamic props. Static strings map directly; dynamic values use the colon-prefixed syntax so Antlers evaluates them before handing them to the component:

{{ blade:alert type="success" }}
    Static message
{{ /blade:alert }}

{{ blade:alert :type="entry:status_type" }}
    {{ title }}
{{ /blade:alert }}

Slots and rich content. Anything between the opening and closing tag is passed through as the default slot, so you can nest Antlers tags and modifiers inside it:

{{ blade:card :title="title" }}
    <p>{{ content | markdown }}</p>
    {{ if featured }}<x-featured-badge />{{ /if }}
{{ /blade:card }}

For named slots, follow the tag naming convention your version exposes (usually a nested tag or attribute such as slot:footer). Check the package source if the syntax isn't obvious from the README.

Collection loops. The biggest day-to-day win is rendering a Blade component per entry:

{{ collection:products }}
    {{ blade:product-card :product="id" :featured="featured" }}
{{ /collection:products }}

Pass the entry id (or slug) and let the component class resolve the model via Entry::find() — this keeps the Antlers template thin and pushes formatting/business logic into the component.

Wrap third-party Blade components. Packages like laravel/packages or your own design system ship Blade components. The Antlers tag is a thin adapter, so you don't need to re-implement them — just pass the props through.

Mix and match. You can render a whole Blade view from Antlers for complex sections, then keep Antlers for content-driven markup. Use the tag for isolated widgets and a Blade view ({{ view:checkout }}) for full pages where Antlers offers little.

Component classes with injected services. Because the component is a real Laravel component, you can constructor-inject services (a Cart, a repository, an API client). Keep the Antlers side dumb and pass only identifiers.

Shared component library. If you have a Laravel app plus a Statamic site, this lets one resources/views/components directory serve both — one source of truth for buttons, badges, modals.

Gotchas and Tips

Escaping and expressions differ between Antlers and Blade. prop="x" passes the literal string x, while :prop="var" evaluates the Antlers expression. If a prop is coming out as "var" instead of its value, you're missing the colon — and vice versa if a plain string is being evaluated unexpectedly.

Attribute casing and kebab-case. Antlers is lenient about case but Blade props are camelCase in the class and kebab-case in the template. If a prop silently doesn't reach the component, check the casing in the component's render() / data() method.

Namespacing. Package-provided components (e.g. vendor::button) may need a different prefix or a config entry to be resolvable. If blade:alert works but blade:vendor::thing doesn't, check the config for a namespaces array.

Last release was May 2022. That predates several Statamic 4/5 changes. Before adopting:

• Confirm the service provider still boots (php artisan about and check for errors).
• Verify the Antlers parser hooks still register — Antlers had internal refactors around 3.x→4.x.
• If it breaks, the fix is usually a small change to the tag registration; the concept (a custom Antler tag that instantiates a Blade component) is simple enough to reimplement if needed.

Performance is not free. Rendering a Blade component from Antlers means the template compiler runs twice (Antlers, then Blade). For large collections this adds up. Cache aggressively with {{ cache }} around collection loops, and prefer Antlers partials for very hot paths.

Debugging. If a component renders blank:

• Try the same component in a plain Blade view to isolate whether it's the package or the component.
• php artisan view:clear and php artisan config:clear after any config changes — the tag registration is cached.
• Dump props from the component's data() method to see what Antlers actually passed.
• Check storage/framework/views for the compiled Antlers output if the tag is producing empty strings.

Extension points. Most of the value is in the service provider: you can register your own Antler tag pointing at the same component resolver, override the resolver, or add a config-driven map of Antler tag names → Blade components. Don't fight the tag syntax if you need something different — wrap the resolver.

Statamic's native Blade support overlaps. Statamic can render .blade.php views directly via {{ view:name }}, and you can @include Blade partials from within those views. For new work, ask whether you actually need Blade components inside Antlers or whether a full Blade template is a cleaner fit. This package shines specifically when the surrounding page must stay in Antlers (e.g. content authors edit it in the CP) but you want component-level encapsulation.

Low star count, zero dependents. Treat it as a small utility rather than a load-bearing dependency. Vendor it, or keep a fork in packages/ with your own patches if you rely on it heavily.