How do I install imanghafoori/laravel-widgetize in a Laravel app?

Run composer require imanghafoori/laravel-widgetize in your project. The service provider is auto-discovered, so there is no manual registration step on supported Laravel versions. You can optionally publish the config file to change the default widget namespace, then create your first widget class.

Which Laravel and PHP versions does laravel-widgetize support?

The package is aimed at modern Laravel monoliths and current releases target Laravel 9 through 11 on PHP 8.1 or newer. Because it is effectively a single-maintainer package with its last release in June 2024, check the composer.json constraint against your Laravel major before adopting it. If you are moving to Laravel 12 or later, spike the install first and be ready to fork or pin.

How do I create and render a widget in Laravel?

Create a class in the configured widget namespace with a public render() method that returns what the fragment needs, typically an array of view data or a rendered view. Render it from Blade with @widget('MyWidget') or programmatically through Widget::run('MyWidget'). Move the data fetching into the widget so your controller only has to return the page view.

How does caching work with laravel-widgetize widgets?

The package caches the rendered output of a widget, so repeated requests skip the PHP work for that page fragment. You control it per widget with the $cacheTime property or the cacheFor() method, and you can attach cache tags for targeted invalidation. Caching is opt-in, so you decide which fragments are worth caching and for how long.

Which cache drivers support widget caching and cache tags?

Tag-based invalidation requires a taggable store such as Redis, Memcached, or the array driver. If you are on the file or database cache driver, plan for TTL-only invalidation or switch drivers. This is the single decision that most affects whether the package delivers its headline speed benefit.

How do I avoid caching authenticated or per-user widget output?

Never cache a widget whose output depends on the current user behind an unkeyed cache entry, because that becomes a one-line data leak. Include the user, tenant, or locale identifier in the cache key or tag so each variant is stored separately. Treat this as a team convention enforced in code review, since the package makes caching easy but does not make it safe.

Can widgets be nested inside other widgets?

Yes, a widget view can render other widgets with the same Blade directive. Each nested widget is cached independently, so a long-lived outer cache does not freeze the inner fragment. Keep in mind there is container resolution overhead per widget on a cache miss, so avoid deep nesting on hot paths.

How do I test a widget class without an HTTP request?

You can instantiate the widget class directly and assert on the output of render() without booting a full request cycle. That keeps widget tests fast and focused on the fragment's data and markup. Add at least one Blade-level test that renders @widget('Name') so a renamed or removed class fails in CI rather than in production.

Is laravel-widgetize still maintained, and what are the alternatives?

It is effectively a single-maintainer package at around 900 GitHub stars with its last release in June 2024. That is acceptable for a small view-layer helper, but it means your team owns the upgrade risk against future Laravel majors. Alternatives include plain Blade partials wrapped in Cache::remember, Laravel view components, or Livewire when you need client-side interactivity.

Should I use laravel-widgetize with Livewire or Inertia?

Usually no, because Livewire and Inertia already own the component and caching boundary, so adding Widgetize creates two competing composition models. It fits best in a server-rendered Blade monolith that is not already fully cached at the CDN edge. In those setups a second in-app cache layer adds invalidation complexity for little gain.

Laravel Widgetize Laravel Package

Laravel Widgetize is a package for organizing Laravel application UI into reusable, self-contained widgets. Instead of bloating controllers and Blade views with query logic, you define a widget class that encapsulates its own data preparation and rendering, then include it anywhere with a simple directive. This keeps controllers thin and views clean, while making each piece of the interface independently testable and cacheable.

Widgets are resolved through Laravel's service container, so dependency injection works naturally. The package also provides optional output caching with fine-grained control over cache keys, expiration, and invalidation, letting you speed up expensive view fragments without touching the rest of the page.

Turn any Blade fragment into a reusable, class-based widget
Clean separation of data logic from presentation
Service container aware, so dependencies inject automatically
Built-in caching of rendered widget output
Simple Blade directive for embedding widgets in views