`required` becomes undefined for fields with more than 2 levels of depth

[davidesigner]

Describe the bug and the expected behavior

Here is the problem:

• fields.subFields.required → boolean
• fields.subFields.subSubFields.required → undefined (❌ should be boolean)

Environment:

• React Router 7
• Zod 4
• Conform 1.8.2

Conform version

v1.8.2

Steps to Reproduce the Bug or Issue

Create a Zod 4 Schema with 2 levels of depth:

const Schema = z.object({
  isRequired: z.string(),
  items: z.array(
    z.object({
      isRequired: z.string(),
      subItems: z.array(
        z.object({
          shouldBeRequired: z.string(),
        }),
      ),
    }),
  ),
});

Then, you will see:

const [form, fields] = useForm({
  id: "my-form",
  constraint: getZodConstraint(Schema),
  onValidate({ formData }) {
    return parseWithZod(formData, {
      schema: Schema,
      formatError: (issues: z.core.$ZodIssue[]) => formatError(t, issues),
    });
  },
  defaultValues: {
    isRequired: "",
    items: [
      {
        isRequired: "",
        subItems: [
          {
            shouldBeRequired: "",
          },
        ],
      },
    ],
  },
  shouldValidate: 'onBlur',
  shouldRevalidate: 'onInput',
});

console.log({
  isRequired: fields.isRequired.required, // true
  items: {
    isRequired: fields.items.getFieldList()[0]?.getFieldset().isRequired.required, // true
    subItems: {
      shouldBeRequired: fields.items.getFieldList()[0]?.getFieldset().subItems.getFieldList()[0]?.getFieldset().shouldBeRequired, // undefined
    },
  }
});

What browsers are you seeing the problem on?

Chrome

Screenshots or Videos

No response

Additional context

No response

[chimame]

hi @davidesigner

Are you setting the wrong property for useForm? It should be defaultValue instead of defaultValues. If you're actually using defaultValue and this behavior occurs, please share a reproducible repository. I haven't been able to reproduce the issue when using defaultValue.

[davidesigner]

Hi @chimame,

I made a mistake when opening the issue, but my code does have defaultValue without an “s” and I have the issue.

Please find a reproducible repository here: https://codesandbox.io/p/sandbox/j7wmhk

[chimame]

Thank you for providing the reproducible code. I identified and fixed the issue.
The pkg.pr.new version should resolve the problem, so please give it a try.

[davidesigner]

Thank you for the quick fix, this is working well!

I hope you can include it in the next official version within the next few days 🙏

[chimame]

hi @davidesigner

Conform v1.9 has been released.
The bug in this issue has been fixed among the released fixes. The fix itself appears to have been made quite some time ago.

Please try the new version.

[davidesigner]

This is working well @chimame, thanks a lot!

[davidesigner]

Hi there,

I found another problem that's pretty much the same as the last one.

It happens when fields are nested within a discriminatedUnion.

Here is a reproductible example: https://codesandbox.io/p/sandbox/622dks (v1.15.0).

PS : you can see the same schema is working without discriminatedUnion: https://codesandbox.io/p/sandbox/j7wmhk.

It would be nice to fix it 🙏

[edmundhung]

The case with discriminatedUnion is a bit tricky. As a field can be required conditionally based on the type. Imagine an Article discriminated union type:

type Article = {
  type: 'blog';
  title: string;
  content: string;
  category: string;
} | {
  type: 'announcement';
  title: string;
  content: string | undefined;
};

Which fields should have required: true? The constraint are derived upfront. It is also quite tricky to compare it against the current form value.

[davidesigner]

Thanks for the explanation @edmundhung!

I understand the complexity with discriminatedUnion - the required status is indeed conditional on the discriminator value.

I ended up creating a custom helper that handles this case by accepting an optional discriminator value:

// Usage for simple schemas
isRequired(Schema, 'items[0].text') // → true/false

// Usage for discriminatedUnion - pass the discriminator value
isRequired(Schema, 'currentTranslation.title', { variant: 'static' }) // → true
isRequired(Schema, 'currentTranslation.mobileImage', { variant: 'promo' }) // → true

The helper navigates the schema tree and, when it encounters a discriminatedUnion, filters to the matching variant before continuing.

Suggestion: Would it be possible for Conform to expose something like this? Either:

1. A getFieldRequired(schema, path, discriminatorValue?) utility
2. Or update FieldMetadata.required to accept an optional context/discriminator parameter

The current field.required works great for simple schemas, but for discriminatedUnion it always returns the "worst case" (required if any variant requires it), which isn't always what we want for UI display.

Happy to share my implementation if it helps!

https://gist.github.com/davidesigner/07bdef091b3466787d38a672820452c5

It includes:

• isRequired(schema, path, discriminatorValue?) helper
• Unit tests covering all Zod schema types
• "Canary" tests to detect Zod internal breaking changes

I let you close the issue if you want, thanks again 🙏

[edmundhung]

Happy to discuss more on how we can make it better. Maybe we could improve getZodConstraint to behave more closely to your implementation.

Back to my original example:

type Article = {
  type: 'blog';
  title: string;
  content: string;
  category: string;
} | {
  type: 'announcement';
  title: string;
  content: string | undefined;
};

Is the case you want support mostly on properties exist only on one variant (e.g. category)? Right now I think the behavior is that only type and title is considered required. But it is debatable whether category should be required too. As developers will display the category field only when type is blog in general. It might be an acceptable trade off here and might be enough for most people having a discriminated union?

To support content, we do need something similar to what you have implemented:

function Example() {
  // We can also call useFormData here, but it's awkward to call it before useForm 😅 
  const [type, setType] = useState("blog");
  const { form, fields } = useForm({
    constraints: getZodConstraint(articleSchema, { type }),
  });

  // ...
}

However, how would that work with nested discriminated union? I wonder if we could have a local constraint to override it at the fieldset level:

const articleFields = fields.article.getFieldset({
  // Override default constraint at the fieldset level
  constraint: getZodConstraint(articleSchema, { type });
});

This will also solve another edge case with recursive schema where it's hard to create a mapping between the field name and the validation attributes.