Dashboard For Laravel Laravel Package

Getting Started

• Install the package and publish its config in the usual Laravel way (composer require …, php artisan vendor:publish), then confirm the service provider is auto-discovered. Validation still comes from your FormRequest / $request->validate(); the package layers the client-side form state, error summary and repeater behaviour on top.
• Read first, in this order: the DXFormErrorSummary docs, the SubmitFailure.failedRows reference, and the repeater docs (especially softDeleteKey and rowLabel). Those three pages explain almost everything the package does that raw Laravel validation does not.
• The fastest first use case: one form with a single repeater (lines.*.name, lines.*.qty), server-side rules, and an error summary at the top. Submit it with an invalid row and click the summary entry — you should land on the offending row's control. That single loop exercises the failure payload, the summary, row identity and row labels.
• Wire the failure response into the form as soon as the response arrives (submitFailure.failedRows is read from the form data at that moment). Everything downstream — the summary, per-row error display, scroll targets — is derived from that snapshot.

Implementation Patterns

• Error summary as the primary navigation surface. Render the summary from submitFailure.failedRows rather than walking the error bag yourself. Each summary entry carries the failed row so a click can scroll to and focus the right control, and so a row that no longer renders (removed, or soft-deleted and filtered out) degrades gracefully.
• Row editors and span/value slots. Use these slots for compound fields (a address object with address.street / address.postcode, or a repeater row's sub-form). The update you receive now clears errors under <key>. only when the array's rows actually changed by identity (added, removed, replaced, reordered). Write the array back on every keystroke and the other rows keep their errors — that is the intended pattern.
• Soft deletes in repeaters. Flag rows with softDeleteKey instead of splicing them out when you need stable indices (drafts, undo, server-side diffing). The summary now treats a flagged row as gone, so its error entry scrolls to the list field rather than hunting for a row that is no longer rendered.
• rowLabel(row, index) for human names. Build labels from the index the function receives rather than from a stashed index — it now reflects "the row's current position while it exists, the position it failed at once it is gone", which keeps your "(line N)" text consistent with the summary's own line form.
• submitFailure.failedRows as a read model. Treat it as immutable after capture: read it for labels, scroll targets and jump-to-error. Don't mutate it, and don't recompute row positions from it later.
• Integration tip: keep the server response shape stable (message, errors, failedRows) and let the package own the mapping. If you use a submit transform, apply it only to the outgoing payload, never to the array identity the form already holds.

Gotchas and Tips

• failedRows is a snapshot, not a live pointer. It is captured from the form data when the failure response arrives. Rows added, removed or reordered while the request was in flight — or dropped/reordered by a submit transform — can attach an error to the wrong row. This is inherent to bare index keys; mitigate by disabling structural edits during submit, or by keying rows with a stable client id and reconciling on response.
• Bare index keys lie. lines.2.options.0.name resolves to whatever lines.2 is now. If your UI permits reordering mid-flight, expect the occasional mis-targeted error and design the UX (disable, buffer, or optimistic-resync) around it.
• Row copy semantics when a failed row no longer exists. File and Blob values are cloned. A row falls back to a shallow copy when it holds a function, a symbol, a DOM node or a nested reactive object — mutations after capture can leak through. A class instance is copied as a plain object, so getters and prototype methods are lost; don't call instance methods on a captured failed row.
• failedRows only records the first numeric segment's row (lines.2 for lines.2.options.0.name), and nested rows are deep-cloned. That is the only row the summary reads — don't build your own traversal expecting deeper entries.
• Soft-deleted ≠ present. If you relied on 0.47.1 behaviour where a flagged row still counted as renderable, summary clicks will now land on the list field. Make sure the list field has a visible label/legend — that is what gets focus (a repeater's labelled group announced by its legend, or a span field's container), and focusability is applied for that focus only, so nothing extra to configure.
• Don't clear errors yourself on every update. Prior to the fix, blanket update clearing wiped sibling rows' errors; now only identity-changing array updates clear <key>. errors, and other updates clear only the field's own error. If you added a workaround to re-hydrate errors after each keystroke, remove it — it will now fight the package.
• Debugging scroll/focus misses: check (1) failedRows was captured before any local mutation, (2) the row still renders or is correctly soft-deleted, (3) rowLabel uses the passed index, (4) no submit transform reorders rows. Those four cover nearly every "click goes to the wrong place" report.
• Upgrade note: 0.47.2 is a pure bug-fix release correcting several 0.47.1 regressions (error-clearing on every update, incorrect summary focus target, soft-deleted rows counted as present, rowLabel index drift). If you are on 0.47.1, upgrade and drop any workarounds you added for those.