- What does digital-creative/icon-action-toolbar do?
- It is a presentation-layer package that re-renders the row actions you already define on a Filament resource table as a compact toolbar of icons instead of full text buttons. Icons, colors, and tooltips are configurable, and it composes over the framework action and authorization APIs rather than replacing them. The payoff is denser, easier-to-scan index tables on high-traffic admin screens, not new functionality.
- How do I install icon-action-toolbar in a Laravel app?
- Install it with Composer pinned to an exact version, so run composer require digital-creative/icon-action-toolbar with a fixed version constraint rather than a range. Then follow the README to register the plugin or service provider for your panel and publish any assets if the package ships them. Because a patch release has already changed the DOM and CSS contract, avoid floating constraints and commit the lock file. Verify the install on a single resource before rolling it out.
- Is this package for Filament or Laravel Nova?
- This is the single most important thing to confirm before you plan any work. The package description says Filament, but the changelog references nova:publish and a nova-packages-toolbar, and technical reviews of the shipped tags describe Laravel Nova, which is a different framework with different registration surfaces and asset pipelines. Check composer.json and the src directory at the exact tag you intend to pin and confirm the framework before estimating anything. If the answer does not match your stack, the correct decision is to reject the dependency.
- Which Filament, Laravel, and PHP versions are supported?
- There is no published compatibility matrix, so treat version support as unverified until you read composer.json at the tag you are pinning. Test against the exact panel version you run today rather than upgrading anything to accommodate the package. If you adopt it, record the tested combination in your own dependency notes so future bumps are checked against a known-good baseline.
- How do I configure icons, tooltips, and colors for each action?
- Configuration is fluent and lives on the action definitions themselves, so you call icon, color, and tooltip or label methods on the same action objects you already register in the resource table. Keep custom behavior in PHP action subclasses and never fork or patch the package Vue components, because that is what keeps the dependency cheap to carry. Establish a shared icon order, such as view, edit, replicate, custom actions, then delete, in a base resource or trait so new resources cannot drift.
- Does the toolbar respect policies, visibility rules, and confirmation dialogs?
- Yes, in principle, because the package renders your existing action definitions, so visible, authorize, and requiresConfirmation continue to be evaluated by Filament or Nova rather than by the toolbar. That is the architectural reason to prefer it over hand-built icon buttons. Still, verify confirmation dialogs and policy-driven hiding on a real resource in your panel, since icon-only rendering makes a wrongly visible action much easier to click.
- Is an icon-only action column accessible?
- Icon-only rendering degrades accessibility if the accessible name is supplied only by a hover tooltip, because tooltips are not reliably announced and do not help keyboard or touch users. Check that each icon button exposes a proper label or aria-label and has a visible focus state in both light and dark mode. The safest default is mixed rendering: icons for benign actions and a labelled button for anything destructive.
- Can I keep a labelled button for delete while using icons for everything else?
- Yes, mixed rendering is the recommended pattern on triage screens, and it is a configuration choice rather than a package limitation. Delete and other destructive actions lose the label that was doing safety work, so gate them behind requiresConfirmation and keep the text visible. Confirm the mixed layout still aligns cleanly at your table density before shipping it to users.
- Is this package stable enough for production?
- Treat it as early-stage: it is on 0.1.x with a small star count, zero dependents, and a single maintainer, and a structural refactor landed in a patch release that moved the toolbar onto a shared component and fixed a replicate-icon bug. A patch release that changes DOM and CSS contracts is a clear signal the extension surface is still moving. Pin the exact version, budget QA time for every bump, and make sure you have a one-line fallback to labelled buttons if it misbehaves in production.
- When should I avoid this package, and what are the alternatives?
- Skip it on low-frequency or data-entry resources, where labels do real safety work and the density gain is worth nothing. It also makes little sense if you already override CSS on the action column and nobody owns re-verifying those overrides in light and dark mode. Alternatives are native Filament action groups or dropdown menus, individually configured icon buttons on each action, or a small bespoke toolbar if the framework check above shows the package targets the wrong framework entirely.