Nova Dynamic Resources Laravel Package

Getting Started

• Install with composer require opscale-co/nova-dynamic-resources and run composer update if you are upgrading to v1.12.0.
• Publish any package config/assets as documented, then clear caches: php artisan vendor:publish --tag=nova-dynamic-resources-config (tag name may vary), php artisan config:clear, php artisan cache:clear.
• Look first at:
  • config/nova-dynamic-resources.php (catalog sources, field registry, storage defaults)
  • Your existing app/Nova resources and any dynamic resource schema definitions
  • The package’s field classes, especially the new multiselect catalog-backed field added in v1.12.0
• First use case: create a small catalog model/table (for example, tags), seed a few rows, and add a multiselect catalog-backed field to one dynamic resource. Verify that selecting multiple catalog entries persists correctly and renders in index/detail views before rolling it out to larger resources.

Implementation Patterns

• Catalog-backed multiselect for many-to-many style data. Use the v1.12.0 multiselect field for tags, categories, skills, permissions, or similar datasets where users need to pick several values from a controlled catalog. Keep single-select catalog fields for hierarchical or mutually exclusive choices.
• Define the catalog first. Create a migration and Eloquent model for the catalog table, seed baseline values, then register that catalog with the package’s config or field definition. This keeps option lists maintainable instead of hard-coded.
• Wire the field into your dynamic resource schema. Add the multiselect field where other dynamic fields are declared, point it at the catalog source, and confirm whether the package stores selections as a JSON array, a pivot table, or another relation. Match your migration and model casts to that storage format.
• Validate at the boundary. Use array validation plus per-item existence checks, for example ['array', 'exists:catalog_table,id'], and add wildcard rules such as field.* where needed.
• Consume stored values in application code. If selections are stored as JSON, add an array cast on the model. If stored via pivot, define the relationship and eager load it in Nova and application queries to avoid N+1 issues.
• Use catalogs as a shared integration point. Centralize frequently reused option sets (departments, regions, product lines) in catalog tables and reference them from multiple dynamic resources. This is where the package pays off day-to-day: one catalog update propagates to every resource using it.
• Build admin workflows around Nova. Combine the multiselect field with Nova policies, searchable/async option loading if supported, and dependent fields where one catalog filters another. Test the form payload in the browser network tab to confirm how selected IDs are submitted.

Gotchas and Tips

• Confirm the storage contract before writing migrations. The multiselect field may store an array of catalog IDs or create pivot rows. Check the package docs/source for v1.12.0 and align your column type, casts, and relationship definitions accordingly.
• Catalog deletion can orphan selections. Add soft deletes or restrict deletion on catalog records, and validate that stored IDs still exist. For JSON-backed fields, consider a cleanup command or observer when catalog rows are removed.
• Watch option-loading performance. Catalog-backed multiselects can load large option sets. Index the catalog label columns, enable searchable/async loading if the field supports it, and avoid loading full catalogs into every Nova index request.
• Validation needs per-item rules. A top-level exists rule is not enough for multiselect arrays; use wildcard rules and test both create and update flows.
• Clear caches after config changes. Catalog registration and field configuration are often cached. Run php artisan config:clear and php artisan cache:clear when options do not appear as expected.
• Debug from the Nova payload. If selections do not save, inspect the form request payload, the field’s resolved options, and the model’s fillable/casts. Check whether the field is read-only or excluded from the resource’s form context.
• v1.12.0 is additive. The multiselect catalog-backed field is a new feature; there are no breaking changes called out in the release notes. Upgrading should be low-risk, but re-test existing dynamic resources after composer update, especially if you publish package assets and need to rebuild front-end assets.
• Extension points to know. Look for a catalog interface or option resolver you can override for custom filtering, tenant scoping, or permission-aware catalogs. Use Nova policies and model observers to keep catalog-backed fields consistent with the rest of your application.