Laravel Blade Helper Laravel Package

Getting Started

• Install with composer require imliam/laravel-blade-helper. The service provider is auto-discovered — there is no publish step, no config file, and no migrations. If you're upgrading from v1.6.x, this is a drop-in composer update with no application code changes.

• First thing to check after install: the README's usage block and the tests/ directory. The package surface is intentionally tiny, so the tests double as the best documentation for edge cases (empty data, nested directives, escaping).

• First real use case: rendering a Blade string rather than a view file. Reach for it when the template doesn't live on disk — an email body stored in a database column, a notification fragment built in a queued job, an HTML snippet passed to a PDF renderer, or a fixture in a test.

• Verify it works in php artisan tinker before wiring it into anything:

  blade('Hello, {{ $name }}!', ['name' => 'Liam']); // "Hello, Liam!"
  

• v1.7.0's headline change is Laravel 13 support. If you're on Laravel 13 and were previously holding the package back with a conflict entry, a --ignore-platform-reqs flag, or dont-discover, you can remove those workarounds now.

Implementation Patterns

Database-driven templates. This is the strongest day-to-day fit. Store the Blade source in a text column, render on demand, and keep the data contract in a typed array or DTO:

$html = blade($template->body, [
    'user'    => $user,
    'order'   => $order->toArray(),
    'support' => config('mail.support_address'),
]);

Because the template is data, non-developers can edit copy without a deploy — but see the security note below.

Mailables and notifications. When the body is dynamic, render the string and hand the HTML to a Mailable rather than fighting view() path resolution:

return (new MailMessage)->view('mail.raw', ['html' => blade($body, $data)]);

PDF and export generation. barryvdh/laravel-dompdf, snappy, and similar packages accept an HTML string. Rendering a stored or generated Blade snippet straight into the PDF builder avoids creating a throwaway view file per report type.

Test fixtures and assertions. Rendering a snippet inline keeps test setup local instead of adding a blade file per assertion:

$this->assertStringContainsString('Liam', blade('Hi {{ $name }}', ['name' => 'Liam']));

Composition. For anything larger than a fragment, @include, @each, and component tags still resolve against your normal resources/views paths — so you can use a database template as a layout-ish wrapper around real partials. Keep the stored string thin and delegate the heavy markup to file-based views.

Wrapping it. Put the helper behind a small service class (TemplateRenderer) so you have one place to add caching, sanitisation, or a later swap to Laravel's native Blade::render().

Gotchas and Tips

• Security — the big one. Rendering a Blade string is effectively compiling and executing a template. Never pass user-submitted or tenant-supplied content to blade() unless that content is authored by someone trusted. Blade can reach into PHP via directives and {{ }} payloads; treat stored templates as code, gate who can edit them, and prefer an allow-listed directive subset or a sanitiser if editing is exposed in an admin UI.
• No compiled-view cache. File-based views are compiled once and cached in storage/framework/views. String templates generally are not, so every call pays compile cost. On a hot path (per-request emails, list rendering in a loop), memoise the rendered HTML in the cache with a key derived from the template hash plus data, and invalidate on template save.
• Native alternative. Newer Laravel versions ship Blade::render($string, $data) in core, which covers most of the same ground. Prefer native if you're already on a version that has it and want one fewer dependency; keep this package if you want the terse global helper or need to support older Laravel releases in a shared codebase.
• Escaping surprises. {{ $value }} escapes, {!! $value !!} does not. In email/PDF contexts people often want raw HTML from a rich-text field — be deliberate, and remember the compiled output is what gets cached, not the escaped input.
• Components and anonymous components. Class-based Blade components resolve through the container and work, but anonymous components relying on $component internals or @props inside a string template can behave differently than in a view file because there's no originating view path. Debug by rendering the same markup from a temp view file and diffing the output.
• Errors are opaque. A syntax error in a string template surfaces as a BladeCompiler/ErrorException with a compiled-file line number that doesn't map to your stored string. Log the offending template ID alongside the exception, and validate templates on save (compile-check them in a try/catch) rather than at send time.
• Config cache. The provider is auto-discovered; if you ever add dont-discover (e.g. as a Laravel 13 workaround), remember php artisan config:clear — and remove the entry now that v1.7.0 supports Laravel 13.
• v1.7.0 test-suite migration is internal. The move to PHPUnit 12 #[Test] attributes and the updated phpunit.xml.dist affect the package's own CI only. If you fork the package or run its tests in your own pipeline, note that PHPUnit 12 drops older annotation-style metadata and requires a correspondingly modern PHPUnit — your application's own test suite is unaffected.
• Extension point. The helper is a thin wrapper; if you need different escaping defaults, a sandboxed directive set, or per-tenant cache scoping, wrap it rather than patching vendor code, and pin the package version so a future minor doesn't change compiled-output semantics.