packages/components/form/src/form.vue (2)

46-53: Consider initializing initialValues synchronously for robustness.

The initialValues is set in onMounted, but resetField and setInitialValue could theoretically be called before mount in certain edge cases (e.g., via exposed refs during SSR or testing scenarios). While setInitialValue has a guard with a warning, resetField at line 81 will silently use getProp(initialValues, prop) where initialValues is undefined, potentially causing unexpected behavior.

Consider either:

1. Adding a guard to resetField similar to setInitialValue
2. Initializing synchronously: let initialValues: any = props.model ? cloneDeep(props.model) : undefined

Option 1: Add guard to resetField

 const resetField: FormContext['resetField'] = (prop) => {
   if (!props.model) return
+  if (!initialValues) {
+    debugWarn(COMPONENT_NAME, 'initialValues is not initialized yet.')
+    return
+  }

   const computedValue = getProp(props.model, prop)
   computedValue.value = cloneDeep(getProp(initialValues, prop).value)
 }

---

129-136: Memory consideration: removedFieldPropCache should be cleared after resetting removed fields.

When resetFields() is called without specific properties, removed fields are reset but their entries remain in removedFieldPropCache. This means the cache grows unboundedly in dynamic forms where fields are frequently added and removed.

Clear cache after resetting removed fields

   // then reset the removed fields if no specific properties are provided
   if (properties.length === 0) {
     removedFieldPropCache.forEach((prop) => {
       if (has(initialValues, prop)) {
         resetField(prop)
       }
     })
+    removedFieldPropCache.clear()
   }

packages/components/form/src/utils.ts (1)

50-62: Type safety concern when skipNormalize is true.

When skipNormalize=true, the code casts props directly to string[]. However, the type Arrayable<FormItemProp> permits a single string value (e.g., "foo"). If a caller mistakenly passes a single string with skipNormalize=true, iterating over props as string[] would iterate over individual characters rather than treating it as a single-element array.

Current usage in form.vue is safe since propStrings is pre-computed as string[], but the function signature allows incorrect usage.

Consider either:

1. Documenting that skipNormalize requires props to already be string[], or
2. Adding a minimal guard:

💡 Optional: Add type guard for skipNormalize path

 export const filterFields = (
   fields: FormItemContext[],
   props: Arrayable<FormItemProp>,
   skipNormalize?: boolean
 ) => {
   const normalized = skipNormalize
-    ? (props as string[])
+    ? (isArray(props) ? props : [props]) as string[]
     : ensureArray(props).map((prop) => (isArray(prop) ? prop.join('.') : prop))
   return normalized.length > 0

packages/components/form/src/form.vue (1)

50-50: removedFields retains full FormItemContext references indefinitely.

Entries are only cleaned up inside resetFields (line 121) when a currently-active field matches the same propString. For long-lived forms with highly dynamic fields (e.g., a list that adds/removes items with unique props), stale contexts (including their reactive refs) accumulate. In practice this is bounded by unique propString values and unlikely to matter for typical forms, but worth being aware of.

Also applies to: 74-80

packages/components/form/src/form.vue (1)

70-79: Consider cleaning removedFields in addField to avoid stale entries.

When a field is re-mounted with the same propString, addField pushes the new instance into fields but the old instance remains in removedFields. This stale entry is harmless (it's cleaned up in resetFields at line 122, and removeField overwrites it on the next unmount), but it means setInitialValues will unnecessarily call setInitialValue on the stale context in the interim.

♻️ Optional cleanup

 const addField: FormContext['addField'] = (field) => {
   fields.push(field)
+  if (field.prop) {
+    removedFields.delete(field.propString)
+  }
 }

packages/components/form/src/form.vue (1)

117-117: resetField() is async but its return value (Promise) is silently discarded by forEach.

The static analysis tool correctly flags this. field.resetField() returns a Promise that is not awaited, so any error thrown inside resetField would become an unhandled rejection. The subsequent lines (119–133) don't depend on the resets completing, so this isn't a correctness bug in the current flow, but it silently swallows potential errors.

Consider using a for...of loop or collecting and awaiting the promises if error propagation matters:

♻️ Suggested approach

-  filterFields(fields, properties).forEach((field) => field.resetField())
+  for (const field of filterFields(fields, properties)) {
+    field.resetField()
+  }

This avoids the linter warning while keeping the fire-and-forget semantics explicit.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@packages/components/form/src/form.vue` at line 117, The call
filterFields(fields, properties).forEach((field) => field.resetField()) discards
the Promise returned by field.resetField(), risking unhandled rejections; update
this to either (a) await each reset if you want errors to propagate (use a
for...of loop and await field.resetField()), or (b) keep fire-and-forget but
handle errors explicitly by collecting promises and using
Promise.allSettled(filterFields(...).map(f => f.resetField())) (or Promise.all
with try/catch) so resetField() promises are not silently ignored; locate the
call by the symbols filterFields and resetField in form.vue and implement one of
these patterns.

packages/components/form/src/form-item.vue (1)

369-371: Double deep-clone when called from addField.

When a field is first mounted, setInitialValue(fieldValue.value) is called (line 411), which does cloneDeep(value). Then in addField (form.vue line 77), cloneDeep(field.fieldValue) stores another deep clone into the Map. So the Map gets a clone, and the local initialValue gets a separate clone — both from the same source. This is correct (they should be independent snapshots), just noting the two clones are intentional.

On re-mount, addField calls field.setInitialValue(initialValues.get(...)) (form.vue line 75) which clones the Map value. The prior setInitialValue call on line 411 is then immediately overwritten. This is harmless but slightly wasteful. If performance on mount/unmount cycles matters, the setInitialValue call on line 411 could be deferred to after addField only when the Map doesn't have a cached value. That said, this is a negligible concern for typical form sizes.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@packages/components/form/src/form-item.vue` around lines 369 - 371, The
current mount flow causes an extra deep-clone: field calls
setInitialValue(fieldValue.value) which cloneDeeps into local initialValue, and
addField then cloneDeeps field.fieldValue into the form's initialValues Map, or
on remount addField later overwrites the local initialValue with a clone from
the Map. Fix by deferring the field-side clone: in addField (the function that
registers fields and writes into the initialValues Map) ensure the Map is
populated first and then call field.setInitialValue(initialValues.get(key) ??
field.fieldValue) so setInitialValue only clones when there is no cached value;
alternatively populate the Map before invoking field.setInitialValue so the
field receives the already-stored snapshot and avoids an immediate redundant
clone. Use identifiers addField, initialValues, field.setInitialValue,
field.fieldValue, and the local initialValue in FormItem to implement this
change.