Add View Composer support

[retlehs]

Problem

View::composer() registrations were ignored for Blaze components because Blaze compiles anonymous components into PHP functions that bypass Laravel's normal View factory render path where composing: events are dispatched.

Solution

Composer support is now opt-in behind config:

• config('blaze.view_composers')
• env toggle: BLAZE_VIEW_COMPOSERS=true
• default: false

When enabled, Blaze injects:

$__data = $__blaze->callComposers('component-name', $__data);

into compiled component functions (before prop extraction). This delegates to Laravel’s existing $factory->callComposer() flow using a lightweight ComponentView, so existing View::composer() registrations continue to work without API changes.

When disabled (default), Blaze emits no composer call in compiled output.

Behavior details

• Composer data continues to override incoming component data on key collisions (Laravel parity).
• Component names are resolved at compile time from file path via BladeService::pathToComponentName().
• Index/same-name conventions are handled (foo/index.blade.php -> foo, foo/foo.blade.php -> foo).
• Composers are still skipped for folded components by design (@blaze(fold: true) renders static HTML at compile time).

Why this approach

Alternative	Why not
Intercept View::composer() registration and maintain Blaze-only registry	Duplicates Laravel behavior and increases maintenance complexity
Introduce Blaze::composer() API	Breaks compatibility with existing app-level View::composer() usage
Always-on composer dispatch	Conflicts with runtime overhead concerns raised in review

Config-gating keeps compatibility while making overhead an explicit opt-in tradeoff.

Test plan

Updated coverage includes both enabled and disabled modes:

• Wrapper does not inject composer call by default
• Wrapper does inject composer call when blaze.view_composers=true
• Composers are not fired when support is disabled
• Default props render when no composer is registered
• Composer injects data when no explicit prop is passed
• Composer takes precedence over explicit prop (Laravel parity)
• Composer receives existing component data via getData()
• Wildcard composer (*) applies to Blaze components
• Closure type-hinted as concrete Illuminate\\View\\View works
• Class-based composer resolves from the container
• Index-convention component (nav/index.blade.php) resolves to nav
• Same-name convention component (badge/badge.blade.php) resolves to badge

---

This PR was developed with the assistance of Codex and Claude

[ganyicz]

Hi @retlehs,

thanks for contributing!

This would add non-negligible overhead to the runtime performance. If we were to add support for view composers it would need to be under a configuration option.

My concern is, with this additional runtime overhead, is Blaze still significantly faster than Blade? Are you able to provide real-world benchmarks from an app that uses view composers heavily, comparing Blade vs Blaze (with this PR applied)?

[retlehs]

Thanks for the quick reply. I added the config gate (BLAZE_VIEW_COMPOSERS, default false) and set up a reproducible benchmark app here: https://github.com/retlehs/blaze-benchmarks

I ran:

php artisan bench:composers --iterations=200 --warmup=30

Iterations: 200, Warmup: 30, Components per render: 360

Mode	Total ms	Avg ms/render	Renders/sec	Checksum
blaze-no-composers	148.82	0.7441	1,343.87	4,870,800
blaze-with-composers	405.27	2.0264	493.50	5,412,000
blade	2,143.73	10.7186	93.30	5,134,800

• blaze-no-composers vs blade: -93.06% avg render time
• blaze-with-composers vs blade: -81.09% avg render time

Notes:

• Each mode is run in a separate PHP process to avoid cross-mode function-cache contamination.
• Checksum differences are expected because composers intentionally mutate output in the blaze-with-composers scenario.

Great suggestion on defaulting composer support off. It preserves the zero-cost default path, while apps that rely on composers can opt in and still see a substantial speedup over Blade in this benchmark (~81% lower avg render time).

[ganyicz]

@retlehs would you be able to share some details about the use case for view composers in your app? I would like to understand the needs before we implement these features as they were intentionally left out for the initial release.

[retlehs]

I'm one of the maintainers of https://github.com/roots/sage (a long-standing WordPress starter theme with 10k+ stars) and https://github.com/roots/acorn (2M+ installs) - we even have folks using Livewire within WordPress

We use Blade, and View Composers are used to pass data to the Blade templates

In practice:

• We bind data to specific templates/partials/components
• Composers encapsulate view-specific data logic and keep templates focused on presentation

[ganyicz]

Appreciate the references! Interesting use case, we'll definitely consider this. We would probably add this along with some of the other features that were originally left out like View::share, in which case we would design a unified API for enabling these, but I'll keep this open for now. Thanks for the insights!

[retlehs]

Makes sense to design these together. From implementing composers, View::share looks like it'd follow the same pattern of merging $__blaze->env->getShared() into $__data before extraction, probably even simpler since there's no per-component resolution needed.

Happy to contribute to the unified API design if that would help move things forward.

[ganyicz]

Hi @retlehs,

Thanks for your contribution. We are looking to add support for view composers in Blaze, however I don't feel comfortable shipping this just yet. Blaze has only been out for a week at this point and we are mainly focused on compatibility with other packages and overall reliability. Adding view composers requires a lot of considerations and I would prefer not rushing it as there are some sharp edges. For that reason I'm going to close this PR now but hopefully we will revisit this soon.