- How do I install optimistdigital/nova-simple-repeatable?
- Install it with Composer and then use the field inside a Nova resource definition. Be aware that the vendor namespace moved from optimistdigital to outl1ne, so confirm which Packagist name resolves for your Nova version. Pin an explicit version constraint rather than floating it, and note there is no service provider configuration or migration to publish.
- Do I need a separate database table or Eloquent model for repeatable rows?
- No. Rows are stored as JSON in a single nullable JSON column on the existing table, so there is no child table, no Eloquent relationship, and no shipped migration. You add the column, declare the field in the resource, and start repeating.
- Why does my repeatable field save as null or fail to save?
- The most common cause is a missing cast on the model. You must cast the JSON column as 'array' (or an equivalent JSON cast) on the Eloquent model, otherwise saves can blow up or the value reads back as null. Also confirm the column exists and is nullable JSON rather than a string or text type.
- Which Laravel Nova versions does this field support?
- Support depends on the Nova major version, so check the package's supported matrix before committing. Because this is a small-maintainer package, the field typically trails new Nova releases. Pin the exact tag you verified against your Nova major and never float the constraint, and remember a licensed Nova install is the real gating prerequisite.
- Can I filter, sort, or aggregate on individual repeatable row values?
- Not practically. Rows are ordered array entries inside a JSON blob with no per-row identity or foreign keys, so joining, filtering, reporting, and aggregation on a single row value are not supported. If you will ever query row-level data, use a normalized child model instead of this field.
- Does nested field validation work inside repeatable rows?
- Inner fields accept Nova's usual ->rules() validation, but nested validation is the classic weak spot in fields like this. Verify in a branch that error messages surface at the correct level in your Nova version before designing screens around it. For critical rules, back it up with model-level or request validation.
- Does dependsOn or conditional visibility work inside repeatable rows?
- Reactive and nested-repeatable behavior is the usual breakage point, and conditional visibility keyed off sibling row values is likely unsupported. Treat dependsOn inside rows as unverified until you test it against your Nova version. If your form logic depends on it, prototype first rather than discovering it during UAT.
- How do row ordering and row identity work when editing?
- Rows are sortable with drag-and-drop, and the stored order is simply the array order in the JSON. There are no stable row IDs, so deleting a row renumbers the rest, which rules out deep links, per-row sync, or per-row permissions. Concurrency is last-write-wins with no diff or version history.
- Can I use file uploads or BelongsTo fields inside repeatable rows?
- Uploads and relationship fields can be placed inside rows, but they come with caveats. BelongsTo fields store bare IDs with no foreign key constraint, and files attached to rows can be orphaned in storage when a row is deleted unless you add cleanup logic. Test these cases before relying on attachments inside rows.
- How is the package maintained, and what is the exit plan if it breaks?
- It is a small-maintainer package with roughly 75 stars and few dependents, so treat dependency refreshes as unreviewed until you diff the lockfile. It is MIT licensed, which means the worst case is a fork rather than a rewrite. Keep the resource definition thin by putting the inner field set on a static model method, so swapping the package or normalizing the JSON later is a contained decode-and-backfill migration.