Inconsistent Structure of the errors Object in useForm

[hkiame]

Description

I’ve encountered an inconsistency in the structure of the errors object provided by useForm. When validation errors are generated through the resolver, the errors object structure is as expected, with field names as keys. However, when errors are set manually using setError (e.g., for handling server-side validation errors), the structure changes to an array-like format with numerical keys.

This discrepancy makes it difficult to handle errors uniformly in the application.

---

Versions

• React Hook Form Version: 7.54.2
• Resolver Used: zod

---

Reproduction Steps

1. Initialize a form using useForm and integrate zod as the resolver.
2. Submit the form to generate validation errors using zod.
3. Observe the structure of the errors object — it has field names as keys, e.g.:

   {
       email: { message: "Invalid email format", type: "invalid_string" },
       firstName: { message: "first name must be at least 2 characters long", type: "too_small" }
   }

4. Use the setError function to set errors (e.g., to handle server-side errors).
5. Observe that the structure of the errors object changes to:

{
    "0": {
        "type": "manual",
        "message": { "path": "email", "message": "Invalid email format" }
    },
    "1": {
        "type": "manual",
        "message": { "path": "firstName", "message": "first name must be at least 2 characters long" }
    }
}

Expected Behavior

The structure of the errors object should remain consistent, regardless of whether errors are set manually using setError or generated through the resolver. Ideally, it should always use field names as keys for easy access, such as:

{
    email: { message: "Invalid email format", type: "manual" },
    firstName: { message: "first name must be at least 2 characters long", type: "manual" }
}

[hkiame]

Hi,

I realized that the issue I raised was due to an incorrect implementation on my end. Specifically, I was setting the wrong values in the setError function. Instead of passing field names as keys in the errors object, I was using a different structure, which caused the inconsistencies I observed.