Filament Tree View Laravel Package

Product Decisions This Supports

• Feature scoping for hierarchical data: Fast-tracks admin UX for any entity that is naturally a tree — categories, site navigation menus, org units, product taxonomies, comment threads, CMS page hierarchies, permission groups. If your roadmap has one of these behind a "custom tree editor" ticket, this package collapses that ticket into a config task.
• Build vs. buy for admin CRUD: The alternative is typically a 1–3 week custom Filament/Livewire build with drag-and-drop, cycle prevention, cascade-delete, and accessibility. This package replaces that with a tree() method plus HasTreeStructure trait, so the decision shifts from "do we staff this?" to "do we accept a small third-party dependency?"
• Drop-in replacement for Table on a resource: Because it mirrors Filament's Table API (fields, recordActions, actions, modal edit), it is a low-friction swap when a flat table proves poor for hierarchical content. Useful as a scoped experiment: ship a tree page next to the existing list page and let power users pick.
• Save-mode as a product choice, not an engineering one: autoSave() vs. manual Save/Cancel is a real UX decision (safety vs. fluidity) that PMs can now tune per resource without new scope — e.g., auto-save for small internal taxonomies, manual save for large public-facing menus.
• Depth and read-only as governance levers: maxDepth() enforces information-architecture rules (e.g., max 3 levels of categories); reorderable(false) gives you a viewer-only tree for reporting/audit pages using the same config.
• Relation-page management: TreeRelationPage supports managing a child hierarchy from the parent's record page — relevant if you're deciding between "nested resource" vs. "sub-navigation tab" UX.

When to Consider This Package

Adopt when:

• You are already on Filament 4.x/5.x, Laravel 11/12, PHP 8.2+. Outside that matrix, it is a non-starter.
• Your hierarchy maps cleanly to adjacency list (parent_id + order). Greenfield schemas are trivial; legacy schemas are only viable if you can override getParentKeyName()/getLocalKeyName() to match existing columns.
• You want native Filament feel — actions, modals, dark mode, Filament color/typography enums — rather than bolting on a JS tree widget.
• Your team is small or time-constrained and the tree is supporting infrastructure, not a differentiator.
• You need cycle-safe moves, cascade delete, and keyboard/screen-reader support without building and testing them yourselves.

Look elsewhere or build when:

• You are not on Filament (or on Filament 2/3) — the value proposition is entirely "feels like native Filament."
• You need nested sets, materialized path, closure tables, or multi-tree/forest semantics; adjacency-list assumptions are baked in.
• You require very large trees (tens of thousands of nodes in a single view) or virtualized rendering — evaluate collapsed() and test with production-sized data before committing.
• You need enterprise support, SLA, or a proven dependency graph. At 41 stars and 0 dependents, this is early-adopter territory; the bus factor is essentially one maintainer. Treat it as "small OSS dependency with review overhead," not a vendor product.
• You need multi-tenant or permission-scoped trees with complex move validation beyond circular-reference prevention — likely a custom layer on top.
• License/legal: MIT is permissive and low-risk, but pin a version and add it to your dependency register.

How to Pitch It (Stakeholders)

To executives: This is a small, MIT-licensed add-on that lets us ship hierarchical admin features — category trees, menus, org structures — in days instead of weeks. It reuses Filament, which we already run, and proven libraries (Staudenmeir's adjacency list, Atlassian's drag-and-drop from Jira/Trello). Cost: one Composer dependency, no licensing fee, no new infrastructure. Trade-off: it's young OSS with a small community, so we contain the risk by pinning the version and keeping our own usage thin (one resource, clear fallback to a flat table if needed).

To engineering: The integration surface is deliberately Filament-shaped — add HasTreeStructure to the model, a tree() method to the resource, and a TreePage (or TreeRelationPage for relation sub-navigation). Required schema columns are just parent_id and order, with overridable column names for legacy tables. It ships safe operations (circular-reference guards, cascade delete), configurable depth, and auto-save vs. manual save. Two caveats to own explicitly: (1) it is early-stage — 41 stars, no dependents, single-maintainer risk — so we should read the source for the paths we use rather than treat it as opaque; (2) it is opinionated toward adjacency lists, so if our storage model diverges we are writing adapters. Recommendation: pilot on one low-blast-radius resource, measure node counts and save latency with realistic data, then decide on broader rollout.