An editable Vue list needs a stable way to identify each logical row as items move. Use that identity for edits, validation and actions, then test reordering with similar-looking records. The row's current position is presentation information; it should not accidentally become the identity of a saved business item.
YourBiz in the Vue.js collection provides a repair-management context for this exercise. Imagine an estimate with several parts and labour lines. The scenarios below describe a proposed implementation review, not a claim that the listed product has an identity defect.
Build a sample that exposes mistakes
Create two lines with the same description but different quantities, and a third line with a long description. Give each a distinct internal identity in the test fixture. Edit the second line without immediately saving the entire estimate.
Now insert another line at the top, change the sort order and remove an unrelated line. Check that the unfinished input and its validation message remain attached to the intended record. A sample containing only unique short labels can make a wrong-row update harder to notice.
Use keys for logical identity
Vue's list rendering documentation explains how unique keys help track node identity when list order changes, particularly when child state or input state matters. Choose a stable primitive identifier appropriate to the record.
Do not regenerate every key on each render merely to force the interface to update. That can discard useful state and obscure the underlying ownership problem. Likewise, a current array index may be an unsuitable identity when insertion and reordering are supported.
Define how unsaved new rows receive temporary identities and how those identities relate to the saved record after creation.
Keep actions attached to records
A delete button, expanded detail panel or pending save should carry the intended row identity through the action. After sorting, verify the saved result rather than assuming the visible button position proves the correct request was sent.
Include a delayed response in an isolated test. If the user switches rows before the response returns, the completion handler must not overwrite whichever row happens to be selected now.
Preserve a clear distinction between deleting an unsaved local row and requesting deletion of an existing saved item. They may need different confirmation and error behaviour.
Recompute derived values deliberately
Check that a total uses the current intended rows after insertion, removal and correction. Do not store several independently editable copies of the same derived value unless the domain requires and reconciles them.
When a row is invalid, decide how the preview communicates that incompleteness. A plausible total that silently omits a problematic line can be more misleading than an explicit unfinished state.
The Vue form-value guide covers the meaning of empty and numeric inputs before they enter this calculation.
Include focus and navigation
After a row is added or removed, check where keyboard focus goes. A stable identifier should support an understandable interaction, not merely satisfy a renderer warning. Test increased text size and a narrow viewport so controls remain associated with their labels.
Keep a regression scenario with the original fixture, action sequence and expected final rows. Compare identifiers and values, not just a screenshot. That evidence makes later changes to table layout, sorting or component boundaries safer while preserving the user's work.
