- What is outl1ne/nova-simple-repeatable and when should I use it?
- It is a Laravel Nova field component that renders a repeatable group of sub-fields and persists each row group as a single JSON value on one Eloquent column. Use it for document-shaped data such as FAQ blocks, spec tables, contact lists, pricing tiers, link groups, or metadata pairs. It is the right fit when you want to skip a migration, child model, policy, and related-resource form build. Avoid it for data that needs joins, per-row authorization, workflow, or analytics; a normalized child model is the better choice there.
- How do I install outl1ne/nova-simple-repeatable?
- Install it with composer require outl1ne/nova-simple-repeatable inside an application that already runs Laravel Nova. The package ships no migration, so you own the schema: add a nullable JSON column to the resource table and cast it to array or json on the model. Then add the field to your Nova resource and define the sub-fields. Check the package's composer.json constraints against your pinned Nova, PHP, and Laravel versions before committing.
- How do I configure the repeatable rows field in a Nova resource?
- You define the row structure once with the fluent fields() method, then chain modifiers such as min(), max(), addButtonText(), and stacked(), which is available as of version 3.0.1. Users can then add, remove, and reorder rows directly in the form, and the whole set is saved to the single JSON column. Keep the field definition in one place so the canonical JSON shape stays documented and testable.
- Does it support Laravel Nova 4 and Nova 5?
- Version support is defined by the package's composer.json constraints, not by the README text or the release date, so verify the current tag against your pinned Nova major, PHP version, and Laravel version. A Nova major release is a hard break for third-party fields, so budget upgrade work whenever you move Nova versions. Treat the two-vendor dependency chain as part of your upgrade planning.
- Do I need a migration or a relationship for the JSON column?
- No migration is shipped and no relationship is required. You add a nullable JSON column to the existing resource table yourself and cast it on the model, and the field writes the row array into that single column. The trade-off is that you are deferring relational modeling until reporting, per-row permissions, or workflow needs actually appear. Name that deferral and the trigger for revisiting it before you greenlight the feature.
- How is validation handled for the repeatable rows?
- Nova-declared validation only guards input submitted through the Nova form. Seeders, imports, API endpoints, and artisan commands bypass it entirely, so malformed or stale-shape JSON can enter silently and surface later as blank fields or render errors. Document the canonical JSON shape, validate at the model or import layer where possible, and add a backfill procedure for existing records when the field set changes.
- What happens to existing records when I change the field list?
- Editing the field set causes shape drift: existing records keep the old keys and there is no database-level contract to catch mismatches. Rows missing new keys will render empty and removed keys are simply ignored or orphaned. Assign an owner for the canonical shape and write down the migration and backfill procedure before the first field change ships.
- Will a large number of rows slow down the Nova form?
- The Vue component renders every row, so unbounded row counts degrade form load time and inflate the save request payload. Set a sensible max() in the field definition and keep total cardinality, rows times sub-fields, inside your UI and request-size budget. If a record can legitimately need hundreds of rows, a related resource with pagination is the safer architecture.
- How should I test a Nova resource that uses this field?
- Focus tests on the persistence layer and the shape contract rather than the Vue UI: assert that arrays round-trip through the cast correctly, that legacy rows missing new keys still render or are handled, and that min and max rules are enforced on save. Also test your importers and endpoints, since they write to the same JSON column without Nova validation. A small fixture of old and new shape payloads catches most real-world failures.
- Is outl1ne/nova-simple-repeatable actively maintained, and what are the alternatives?
- It is a single-maintainer package with modest adoption, around 75 stars and no dependents, so there is no SLA and you should budget it as an internally owned tool from day one. The MIT license is your mitigation: you can fork and vendor it if upstream stalls. The main alternative is a normalized child model plus a Nova related resource or custom form component, which costs more setup but gives you joins, per-row permissions, and easier reporting.