- How do I install saade/filament-adjacency-list in a Laravel app?
- Run composer require saade/filament-adjacency-list, then add the package views to your theme CSS with an @source line pointing at vendor/saade/filament-adjacency-list/resources/views/**/*.blade.php. If you use Filament Panels and have no custom theme yet, create one first following the Filament styling docs. After that you can use the AdjacencyList component in any Filament form schema.
- Does this package support Filament 4 and Filament 5?
- Yes, the changelog shows explicit Filament 4 and Filament 5 support work, landing alongside Laravel 12 and 13 support. The important caveat is that Filament majors are the real compatibility axis, so plan on upgrading the package on Filament's release cadence rather than your own. Check the composer.json constraints against your runtime floor before adopting.
- Can I use it with Eloquent relationships instead of a plain array?
- Yes, the component works with arrays or Eloquent relationships. You can expose a self-referential children() relation on your model or adopt Staudenmeir's HasRecursiveRelationships. The README documents the interop, including the getPathSeparator() and getCustomPaths() workaround for teams already using that trait elsewhere, so coexistence is anticipated.
- How do I set a maximum depth for the tree?
- Call maxDepth() on the component, for example maxDepth(2); the default is -1, which means unlimited depth. Depth is enforced in the drag-and-drop client layer, and the v4.2.0 notes mention fixes for depth limit miscounts on drag. Test your specific depth rules manually after upgrading.
- How do I change the label displayed for each node?
- Use labelKey('name') to change which array key is used for display; it defaults to 'label'. For full control, pass a closure to itemLabel(), which receives the item array and returns a string or null, so you can look up a record by id. The children key is configurable too via childrenKey() when you are not using relationships.
- Can clicking an item open a URL or trigger an action?
- Yes, itemAction() accepts actions such as edit, view, delete, moveUp, or indent, and itemUrl() takes a closure that receives the item array and returns a URL. A common pattern is returning YourResource::getUrl('view', ['record' => $item['id']]). Both are configured on the AdjacencyList component in your form schema.
- Does it support drag-and-drop reordering, indenting, and outdenting?
- Yes, the component is built around drag-and-drop nesting and reordering, including indent and outdent behavior and max-depth enforcement. Behavior is controlled with per-field switches like addable, editable, deletable, reorderable, moveable, and indentable, so you can express read-only or policy-limited modes declaratively. Modal versus inline editing is also configurable.
- Is it safe to use in production for large trees?
- Treat it as an early-adopter package: adoption signals are thin, the bus factor is one primary author, and the most regression-prone parts are the Alpine and JavaScript drag interactions. The v4.2.0 release fixed persistence issues around saving graph relationships without detaching siblings and keeping the tree empty until the owner record is saved, which shows tree mutation bugs can have real data-integrity consequences. Validate render and save performance at your realistic maximum size and depth, and keep a named owner for a potential fork.
- How do I test a Filament adjacency list form?
- There is no dedicated testing guide in the README, and the drag, indent, and reorder behavior lives in client-side state that is the least testable part of the package. Test the underlying model relations and save logic with standard Laravel feature tests, and cover form fill and save paths with Filament or Livewire component tests. Do not assume the drag state machine is covered by your suite.
- What alternatives or risks should I consider before adopting this package?
- The package is a presentation and interaction layer over a schema you already own, so its value is near zero outside a Filament panel; for APIs, Nova, Inertia, or customer-facing frontends you would be adopting a tree UI you cannot reuse. It has no audit history, soft deletes, or per-node permissions, so if you need those you must build them around it. Weigh your commitment to Filament for the lifetime of the feature, and whether you are taking one dependency or two if you also rely on Staudenmeir.