Future Export: the useForm hook

[edmundhung]

We are super excited to announce the future useForm hook today! This brings first-class support for React 19 Server Actions, a refined validation setup, and more.

import { useForm } from '@conform-to/react/future';

The motivation

When we first built Conform v1, we had a simple goal: make form state as accessible as possible to developers. We wanted you to just write fields.email.value and have everything work magically.

So we synced all form values into React state and built complex subscription patterns to avoid re-renders. It worked beautifully—until we realized we had created something that was incredibly hard to debug and reason about.

Over the last year, we have been thinking about how to simplify this, and then came the lightbulb moment: Conform already uses the DOM as the source of truth. Why are we duplicating all this state in React? What if we just... didn't?

The new useForm hook is the result of that realization. No form values in React state. The rest of the state like errors or touched fields doesn't change that often, so we can model it with a simple useState. This makes the architecture much simpler and easier to maintain.

What's different

This release has addressed a lot of the outstanding issues with new features and improvements. Here are some of the highlights:

Metadata

The most obvious change is that the new hook returns a structured object instead of an array tuple, with some metadata changes:

• Form props can be accessed through form.props directly instead of using getFormProps(form)
• Form actions like form.validate() and form.reset() are now available on the intent object instead
• Form dirty state (form.dirty) is removed. Use useFormData() with the isDirty helper if you need this.
• Form metadata now offers three methods for dynamic field metadata access: getField(name), getFieldset(name) and getFieldList(name).
• Field values (e.g. fields.email.value) are removed. Use useFormData() to read form values when needed.
• Field initial values (e.g. fields.email.initialValue) are removed. Use fields.email.defaultValue / fields.email.defaultOptions / fields.email.defaultChecked instead.

const { form, fields, intent } = useForm({
  // ...
});

return (
  <form {...form.props}>
    <input
      type="email"
      name={fields.email.name}
      defaultValue={fields.email.defaultValue}
    />
    {fields.email.errors}
    <input
      type="password"
      name={fields.password.name}
      defaultValue={fields.password.defaultValue}
    />
    {fields.password.errors}
    <button>Login</button>
  </form>
);

We have also adjusted the return type of useField(), which returns a single field's metadata instead of an array tuple with both form and field metadata:

import { useField } from '@conform-to/react/future';

function FormField({ name }) {
  const field = useField(name, { formId: 'optional-form-id' });

  // ...
}

The arguments of useFormMetadata() have also changed to accept an object with optional formId instead of a formId string directly.

import { useFormMetadata } from '@conform-to/react/future';

function FormSummary() {
  const form = useFormMetadata({ formId: 'optional-form-id' });

  // ...
}

Validation

Another big change is the validation system. The onValidate callback now receives the parsed payload alongside the FormData and requires you to return a structured error:

import { type FormError, useForm } from '@conform-to/react/future';

const { form, fields, intent } = useForm({
  onValidate({ payload }) {
    const error: FormError = { formErrors: [], fieldErrors: {} };

    if (!payload.email) {
      error.fieldErrors.email = ['Email is required'];
    }

    if (!payload.password) {
      error.fieldErrors.password = ['Password is required'];
    }

    return error;
  },
});

Of course, we have helpers to integrate with popular schema libraries like Zod:

import { useForm } from '@conform-to/react/future';
import { coerceFormValue, formatResult } from '@conform-to/zod/v3/future'; // or "@conform-to/zod/v4/future"
import { z } from 'zod';

// Enhance your schema to coerce form values
const schema = coerceFormValue(
  z.object({
    email: z.string().email(),
    password: z.string(),
  }),
);

function Example() {
  const { form, fields, intent } = useForm({
    onValidate({ payload }) {
      // Parse the payload with zod yourself
      const result = schema.safeParse(payload);
      // Transform zod result into FormError
      return formatResult(result);
    },
  });

  // ...
}

But we have something even better: standard schema support. Simply pass your schema to useForm and it will handle parsing and validation for you:

const { form, fields } = useForm({
  schema,
});

On the server side, you will find a new parseSubmission utility that parses FormData into a structured submission object with a clean payload for easy validation. Use the report helper to send results back to the client:

import { parseSubmission, report } from '@conform-to/react/future';
import { coerceFormValue, formatResult } from '@conform-to/zod/v3/future';
import { z } from 'zod';

const schema = coerceFormValue(
  z.object({
    email: z.string().email(),
    password: z.string(),
  }),
);

export function action({ request }: Route.ActionArgs) {
  const formData = await request.formData();
  const submission = parseSubmission(formData);
  // Validate the payload with zod yourself
  const result = schema.safeParse(submission.payload);

  if (!result.success) {
    return {
      // Create a submission result using the `report` helper
      result: report(submission, {
        error: formatResult(result),
      }),
    };
  }

  // ...
}

We have also improved client async validation support. You can now define async validation directly in your schema and pass it to useForm:

const schema = coerceFormValue(
  z.object({
    username: z
      .string({ required_error: 'Username is required' })
      .refine((username) => isUsernameUnique(username), {
        message: 'Username is already used',
      }),
  }),
);

const { form, fields } = useForm({
  schema,
});

However, validation might trigger regardless of which field the user is typing in, so we recommend using a memoize utility to cache async validation results:

import { memoize } from '@conform-to/zod/future';

const schema = useMemo(
  () => {
    // Cache results so that it skips duplicate requests for the same username
    const isUsernameUnique = memoize(async (username: string) => {
      const response = await fetch(`/api/validate?username=${username}`);
      return response.ok;
    });

    return coerceFormValue(
      z.object({
        username: z
          .string({ required_error: 'Username is required' })
          .refine((username) => isUsernameUnique(username), {
            message: 'Username is already used',
          }),
      }),
    ),
  },
  [],
);

You can also validate manually in the onValidate callback if you need more control. See the examples section below for more details.

Progressive enhancement

The new design takes a more targeted approach to progressive enhancement. You still get core support like preserving user input on validation errors, but some advanced features require additional setup:

• parseSubmission doesn't handle intents automatically
• getButtonProps() method is no longer available

We still believe the best way to build resilient web apps is to use the web platform extensively. However, building a form with a complete no-JS experience introduces additional complexity that not every application needs. The new design still supports full progressive enhancement, but it requires additional setup that we will document separately.

Improved intent handling

Previously, calling multiple form actions required wrapping each in flushSync to avoid form state sync issues. The new intent system eliminates this need:

<button
  type="button"
  onClick={() => {
    // Inserting two items will only cause one re-render now
    intent.insert({
      name: 'todos',
      defaultValue: { text: '', completed: false },
    });
    intent.insert({
      name: 'todos',
      defaultValue: { text: '', completed: false },
    });
  }}
>
  Add Two Items
</button>

You can also access the intent object anywhere in your component tree using the useIntent() hook:

import { useIntent } from '@conform-to/react/future';

function RemoveButton({ name, index }: { name: string; index: number }) {
  const buttonRef = useRef<HTMLButtonElement>(null);
  const intent = useIntent(buttonRef);

  return (
    <button
      type="button"
      ref={buttonRef}
      onClick={() => intent.remove({ name, index })}
      form="optional-form-id"
    >
      Remove
    </button>
  );
}

Additional improvements

Custom error handling: By default, Conform focuses the first invalid field when validation fails. You can now customize this behavior with the new onError option:

const { form, fields } = useForm({
  onError({ error, formElement }) {
    if (error.formErrors) {
      toast.error(error.formErrors.join('\n'));
    }
  },
});

React 19 compatibility: Previously, Conform required a special workaround to disable React 19's automatic form reset behavior. We have adjusted the state model so it now works seamlessly with Server Actions.

Examples

We have updated several examples to showcase the new useForm hook, including a new React SPA example:

• React SPA Example
• React Router Example
• Next.js Example

Try it out and share your feedback! The API is stabilizing, but we are still open to suggestions before the official v2 release.

[afoures]

does this new useForm works with native html reset via <button type="reset" />?

[edmundhung]

Good question! I initially dropped support for the reset button to better align with React 19. In React 19, a reset event is dispatched automatically after a server action, regardless of whether the submission succeeds or fails. That can be problematic, since you might not want the form state to reset when the submission fails.

Another part of the issue is that Conform listens to the native reset event directly, while React intentionally hides it by not calling your onReset handler.

So right now, it doesn't support it. But it could. Should it? 🤔

[edmundhung]

I think supporting reset button is effectively doing this for you:

function Example() {
  const { form, fields, intent } = useForm({
    // ...
  });

  return (
    <form {...form.props} onReset={() => intent.reset()}>
      {/* ... */}
      <button type="reset">Reset</button>
    </form>
  );
}

[edmundhung]

Just give it a second thought and I think there might be issue with the approach above as intent.reset() will dispatch a reset event as well. So we need additional logic to stop it from triggering recursively.

[edmundhung]

I tested this and, surprisingly, the solution above works fine. However, it does run into an infinite loop if you call formElement.reset() manually.

I will make both works with the future useForm hook.

[aaronschwartz]

I see that getFormProps() has been moved to form.props. What is the plan for getInputProps? Will it be rewritten for V2, moved to a field prop, or something else? Also I see that there is no longer a form.errorId prop. I know you're just getting started with V2, I was just wondering what the future holds. I'm starting some new development and would like to start using V2 instead of having to do a huge migration later.

[aaronschwartz]

Thanks for the reply. It was helpful to set all of the aria attributes correctly, but if I know it's not going to be there then I'll just remake a similar function myself. I don't really like the idea of my custom form components being aware of the conform types so I probably wouldn't integrate it directly into my custom components.

[edmundhung]

I don't really like the idea of my custom form components being aware of the conform types so I probably wouldn't integrate it directly into my custom components.

That makes sense. Do your custom inputs expose an interface compatible with native inputs? That has always been my personal preference too, but I do not see it done much in practice, probably because most people prefer rendering the UI library component directly. That is also why I am planning a way to customize metadata.

I am open to rethinking this, either bringing back the props getter, or exposing it as metadata instead (e.g. fields.email.inputProps with the name, validation attributes, and aria attributes).

[edmundhung]

Also I see that there is no longer a form.errorId prop.

This should be fixed in v1.9.1.

[aaronschwartz]

Do your custom inputs expose an interface compatible with native inputs?

That's a good point. I'm currently trying to integrate with the Catalyst library which uses HeadlessUI as the base. It does seem mostly compatible with the native interfaces.

[edmundhung]

I have implemented the custom metadata feature in #1047.

[aaronschwartz]

Whenever I add a file upload input to the page and try to submit the form (to a react-router action), Chrome crashes with a "Error code: RESULT_CODE_KILLED_BAD_MESSAGE". Have you tested with file uploads? I'm not 100% sure what is happening, but if I submit without going through the Conform onSubmit handler then the action works as intended.

[edmundhung]

Does this happen every time for you, or only occasionally? I managed to reproduce it as well, though it seems a bit random on my end. I have some ideas about what might be going wrong and will work on a patch tomorrow. Thanks for reporting it!

[aaronschwartz]

It's 100% if it goes through the Conform onSubmit handler. I also thought it was random at first, but it was because it was working if I submitted quickly before all of the JS loaded so the form was being posted without going through the client side Conform code.

[edmundhung]

Yep, I can reproduce the issue properly now. It looks like the root cause is Conform accidentally updating the file input with the empty default file set by the browser 😓

I will have a patch ready tomorrow.

[edmundhung]

This is fixed in v1.10.0.

[tkoyasak]

Question about form.valid with future API

Hi, thanks for the new future API, I’m trying it out and noticed something I don’t fully understand.

When I use the current API, the form.valid property correctly updates based on validation.
But with the future API, form.valid always seems to remain true, even if the field value is invalid (e.g. greater than 100).

Here’s a minimal example comparing the two:

import { getFormProps, useForm } from '@conform-to/react';
import { useForm as future_useForm } from '@conform-to/react/future';
import { unstable_coerceFormValue as coerceFormValue, parseWithValibot } from '@conform-to/valibot';
import * as v from 'valibot';

const schema = v.object({
  index: v.pipe(v.number(), v.minValue(0), v.maxValue(100)),
});

export function FormWithCurrentAPI() {
  const [form, fields] = useForm({
    shouldValidate: "onInput",
    shouldRevalidate: "onInput",
    onValidate: ({ formData }) => {
      return parseWithValibot(formData, { schema });
    }
  })

  return (
    <form {...getFormProps(form)}>
      <div>Current API</div>
      <div>{form.valid ? "valid" : "invalid"}</div>
      <div>
        <label htmlFor={fields.index.id}>Index</label>
        <input
          id={fields.index.id}
          name={fields.index.name}
          defaultValue={fields.index.defaultValue}
        />
        <div>{fields.index.errors}</div>
      </div>
    </form>
  )
}

export function FormWithFutureAPI() {
  const { form, fields } = future_useForm({
    shouldValidate: "onInput",
    shouldRevalidate: "onInput",
    schema: coerceFormValue(schema),
  });

  return (
    <form {...form.props}>
      <div>Future API</div>
      <div>{form.valid ? "valid" : "invalid"}</div>
      <div>
        <label htmlFor={fields.index.id}>Index</label>
        <input
          id={fields.index.id}
          name={fields.index.name}
          defaultValue={fields.index.defaultValue}
        />
        <div>{fields.index.errors}</div>
      </div>
    </form>
  )
}

Steps to reproduce

• Enter a number greater than 100.
• In the Current API, form.valid becomes false.
• In the Future API, form.valid stays true.

Question

Is this the intended behavior of the future API?
Or am I missing some configuration to make form.valid reflect the validation result?

Thanks a lot!

[edmundhung]

Looks like I misconfigured it to depend on whether there are any form-level errors 😅 I will fix it tonight. Thanks!

[edmundhung]

#1024 should fix the valid metadata issue. Feel free to try the pre-release linked in the comment. I will land it tomorrow.

[tkoyasak]

Just tested the pre-release, and it works correctly. Thanks a lot for the quick fix!

[edmundhung]

This is landed in v1.10.0.

[aaronschwartz]

I notice that server actions feel a little complex in this new version.

It's nice to be able to pass in a standard schema property to the useForm({schema}) property on the client side, but on the server side, it requires a parseSubmission followed by a schema.safeParse followed by a report and then a formatResult all just to make sure the Conform boiler plate is hooked up correctly for everything to work.

It would be nice to have a similar shortcut on the server side such as const result = parseSubmission(formData, schema) with a simple result.conformReply() or something similar.

It's nice to have the granular control over everything, but we lack that same control on the client side. This came up because I was trying to integrate the HeadlessUI 2.0 ComboBox without relying on the useControl hook since the combobox already generates it's own hidden inputs with a custom naming scheme. The problem is that the naming scheme is in the form gym[id], gym[name] which causes Conform to crash when trying to parse the names with Invalid path syntax at position 3 in "gym[id]. On the server side I could make it work by using my own version of a parseSubmission, but there's no similar granularity on the client side that I can find.

[edmundhung]

just to make sure the Conform boilerplate is hooked up correctly for everything to work.

That's fair. The server side is definitely a bit messier to work with right now. From what you wrote, it sounds like you are looking for an experience closer to parseWithZod in v1?

integrate the HeadlessUI 2.0 ComboBox without relying on the useControl hook since the combobox already generates its own hidden inputs with a custom naming scheme.

I have not had a chance to dig into HeadlessUI 2.0 yet. That said, I have not run into a case where you must rely on the inputs generated by UI libraries, aside from progressive enhancement. Since you mentioned multi-inputs, I do not think that applies in your case either. With generated inputs, you lose control over how values are serialized (and, as you noted, the naming too).

I can certainly consider exposing a hook to customize how submissions are parsed from FormData, but at least from my perspective this does not seem like a strong reason to depend on the library-generated inputs.

[edmundhung]

Hopes this makes it simpler on the server: #1041

[oxc]

The new future exports sound great, seems like some corners have been straightened out (or removed) 👍🏻

Do I understand correctly though, that the only way to infer the FormShape is by passing a standard-schema schema prop? Inferring via onValidate is no longer supported.

So if I do not want to rely on schema for some reason, I have to pass the FormShape type parameter manually, correct?

(Click here for Context)

I'm still not happy with Zod's i18n support, even though it has improved with v4. Therefore, I need to pass my own i18n errormap to the parse function, which is not possible via Zod's standard-schema implementation. So I have to either wrap that, or do the parsing in onValidate and pass the inferred type myself. Or find another way to get happy with Zod i18n :)

[oxc]

In v1 we worked around this by complicating the result type and ask you to provide your schema to a special wrapper, but that complicates the types which I wanna avoid in v2.

I like that, I think it was just unexpected coming from v1. It feels a bit like conform is now hard-wired to standard-schema, whereas before it felt like you could plug in any schema even without a library, but maybe that was just an illusion.

Do you think customizing the error globally would be good enough? (https://zod.dev/error-customization?id=global-error-customization)

That's definitely what zod recommends, but I'm still not convinced that won't lead to race conditions in a concurrent setup (like react-router running in express etc., where each request might set a different global language).

I will probably just monkey-patch the standard-schema implementation of my zod schemas, I would like to use a standard-schema anyway.

Yeah, that's because I was trying to simplify the generics setup in the types. I could reconsider it, but I am curious why not just use fields from the useForm hook in your case?

I used to pass FormMetadata to subcomponents that would handle part of the form (e.g. in a multi step wrapper I wrote, but also common form implementation for add/edit forms.), and get the fields from there.
I think I will just pass fields now, but it's currently not easy to define the type for fields, especially because DefaultMetadata is not exported.

For now, I'm extracting it from the useForm return type:

export type FormFields<FormShape extends Record<string, any>, ErrorShape = string> = ReturnType<
  typeof useForm<FormShape, ErrorShape>
>["fields"];

[edmundhung]

whereas before it felt like you could plug in any schema even without a library

One option is to infer the schema shape from the schema output type:

const { form, fields } = useForm({
  onValidate({ payload }) {
    const result = schema.safeParse(payload);
    return formatResult(result, { includeValue: true }); // <- value has the output type
  },
});

With #1041, I may even default includeValue to true, which would make this fairly straightforward to infer.

The catch is that the output type is not always what you actually want:

// Output type: { username: string; password: string }
z.object({
  username: z.string(),
  password: z.string(),
});

// Output type: string
z.object({
  username: z.string(),
  password: z.string(),
})
.transform(value => JSON.stringify(value));

This is not a great example, but i imagine people might do something similar on some parts of their schema. It could be confusing as the form shape inferred from schema (input type) is different from onValidate + formatResult (output type).

And unfortunately, there is no way to infer the input type from the result.

especially because DefaultMetadata is not exported.

DefaultMetadata is not exported yet since I am still working out how customization of metadata should look. That said, I could add a default metadata type parameter to Fieldset, similar to what I already did for FormMetadata and FieldMetadata.

[edmundhung]

@oxc @chimame I would love to hear your thoughts on the inference setup above. Another option might be to offer a way to override the standard schema validation, something like this:

const { form, fields } = useForm({
  schema,
  schemaOptions: {
    // ... whatever you want to pass to the schema
  },
  onSchemaValidate(schema, options) {
    const result = schema.safeParse(payload, options);
    return formatResult(result);
  },
});

The idea of having a separated schemaOptions is that you could define onSchemaValidate once in a context provider, rather than reconfiguring it every time you call useForm, probably near the top of your component tree:

<FormConfigProvider validateSchema={/* same as above */}>
  <YourForm />
</FormConfigProvider>

To make this type safe, you will likely need to define an interface manually:

declare module "@conform-to/react" {
  interface SchemaOptions {
    // ... define the type yourself
  }
}

It might still be tricky to handle the schema type itself (I need to test that), but I wanted to share the idea and see what you think.

[edmundhung]

One down side with this approach is that zod doesn't offer a safeParse API that support both sync and async like the standard schema one 😓 So you will need to define a schemaOption like async: true in v1 to decide whether it should validate with safeParse or safeParseAsync.

[oxc]

So basically the idea is that we could use any standard-schema type, but override how the actual parsing will be handled?

The default implementation of onSchemaValidate will call the standard-schema validate method (which is currently in onValidate)?

It would still tie the type inference to standard-schema, but then again it should be easy enough to create a standard-schema for your own schema, if you really need to use an unsupported/custom library.

For my project, I have already started wrapping the useForm in a custom wrapper that returns both a hook and a action helper, so it is unlikely I would be using the FormConfigProvider. Still sounds like it could be useful to simpler setups / people who don't like their own abstractions.

Regardless, I like the suggestion already for the fact that this could encapsulate the standard-schema parsing in its own method, and not mingle it in onValidate.

[tkoyasak]

Hi, I saw PR #1041 , which adds support for passing schema issues directly to report. That looks really useful!

Do you think the same improvement could also apply to the onValidate callback in useForm?
Right now, we still need to use formatResult, but if onValidate could return issues directly, the code would become simpler and more consistent with report.

// current
onValidate: ({ payload }) => {
  const result = schema.safeParse(payload);
  const { value, error } = formatResult(result, { includeValue: true });
  if (value) setState(value);
  return error;
},

// proposed
onValidate: ({ payload }) => {
  const result = schema.safeParse(payload);
  if (result.success) {
    setState(result.data);
    return null;
  }
  return { issues: result.error.issues };
},

This would:

• align the API between report and onValidate
• reduce boilerplate when working with Zod/Valibot
• still allow formatResult for customization when needed

Would you consider extending the same support to onValidate?

[tkoyasak]

Sorry, my earlier explanation wasn’t very clear. Let me rephrase with a more concrete example.

Right now, if I want to use the actual input values, I end up either:

import * as v from 'valibot';

const dateField = v.pipe(
  v.string(),
  v.regex(/^\d{4}(?:-(?:0[1-9]|1[0-2]))?$/, "YYYY or YYYY-MM."),
);

const schema = v.pipe(
  v.partial(
    v.object({
      title: v.string(),
      creator: v.string(),
      publisher: v.string(),
      mediatype: v.array(v.string()),
      from: dateField,
      until: dateField,
    }),
  ),
  v.forward(
    v.check(
      ({ from, until }) => !from?.length || !until?.length || from.length === until.length,
      "`from` and `until` should have the same format.",
    ),
    ["until"],
  ),
  v.transform((input) => 
    Object.entries(input)
      .filter(([_, v]) => v !== undefined)
      .map(([k, v]) => [k, Array.isArray(v) ? v.join(" ") : v.toString()]),
  ),
  v.nonEmpty(),
);

const transformToUrl = v.pipe(
  schema,
  v.transform((input) => `${API_URL}?${new URLSearchParams(input).toString()}`),
);

1. storing the parsed value in an external state inside onValidate (using safeParse myself), like this:

const [data, setData] = useState(null);

const { form } = useForm({
  onValidate: ({ payload }) => {
    const result = transformToUrl.safeParse(payload);
    if (result.success) {
      setData(result.data);
      return null;
    }
    return formatResult(result);
  },
});

return <div>{form.valid ? data : "inputs are invalid"}</div>;

2. subscribing to useFormData and re-parsing the FormData object manually, like this:

const { form } = useForm({ schema });

const data = useFormData(formRef, (formData) => {
  if (!formData) return null;

  const input = parseSubmission(formData);
  return `${API_URL}?${new URLSearchParams(
    Object.entries(input)
      .filter(([_, v]) => v !== undefined)
      .map(([k, v]) => [k, Array.isArray(v) ? v.join(" ") : v.toString()])
  ).toString()}`
});

return <div>{form.valid ? data : "inputs are invalid"}</div>;

Both approaches work, but in the second one, even though the schema is already applied for validation, I still have to re-parse the form data when I want to consume it.

That’s why I feel it’s often easier to just define a transform in the schema (e.g. zod/valibot) and reuse the result, instead of parsing form data again outside.

[edmundhung]

It seems to me you are just looking for a way to serialize the form data as a search string based on the current formData, what about this?

const { form } = useForm({ schema });
const data = useFormData(form.id, (formData) => {
    if (!formData) return null;

    const searchParams = new URLSearchParams();

    for (const name of formData.keys()) {
        searchParams.set(name, formData.getAll(name).join(' '));
    }

    return `${API_URL}?${searchParams.toString()}`;
});

return <div>{form.valid ? data : "inputs are invalid"}</div>;

For your particular case, I don't think you really need the value. 🤔

[edmundhung]

I think I will go ahead with my suggestion on #1014 (reply in thread). I do plan to add custom form state support soon. But there are other things I want to prioritize first.

[tkoyasak]

Thanks for the example. I see that in my case, generating the search string directly from formData would work.

Your suggestion to pass schemaResult also looks like a very helpful improvement. Since my schema is synchronous, the async limitation you mentioned wouldn’t be an issue for me.

Thanks again for considering this!

[edmundhung]

This is landed in v1.11.0.

[oxc]

I find myself tripping over the missing DefaultMetadata export often when trying to write some abstractions for my forms. For example, I want to write a Field component that takes a FieldMeta with ErrorShape restricted to string, which seems impossible without re-defining DefaultMetadata myself.
Does anything speak against exporting the DefaultMetadata type?

[oxc]

Sorry, I missed that response in the other thread.

[edmundhung]

No worries. I think #1045 should address your issue. I don't expect making any breaking changes on it anymore. If I will change it again, it would just be additional generic with a default type. So it should be safe to use.

[oxc]

Had a quick look, sounds good ❤️

[edmundhung]

This is landed in v1.11.0.

[edmundhung]

I have implemented the custom metadata feature in #1047.

[oxc]

How does that work with asynchronous schema validation on the client side?

I played around with standard schema yesterday, and noticed that some fields would not should validation errors when I submitted the form empty. When I switched from safeParseAsync to safeParse, it worked again.

Does async validation require some kind of suspense around the form elements?

[oxc]

Here are the differences in form.context (scroll down for diff), maybe that already gives you a hint. I'll try to create a minimal example later this week.

https://gist.github.com/oxc/eb7bbae8acd5639274b2c62338b4f588

In case you're wondering: neither the async nor the sync page make any kind of requests after the first render. These serverError/serverIntendedValue in the async case are generated client-side.

[edmundhung]

Thanks, that's probably enough. I can see the issue you had with the services field. Its errors are missing on async validation as it is not considered touched.

Conform does some additional logic on client (sync) validation to mark non existent fields as touched when doing a normal form submit, but that logic is skipped on server (async) validation. So that's likely the reason why this happens.

I will look into a solution tonight.

[oxc]

Thanks. The services are a list of checkboxes, so indeed no value would be present for those.

[edmundhung]

#1048 should fix your issue. Can you give the pre-release a try?

[oxc]

Yep, looks good 👍🏻

The field now shows up in touchedFields

I've updated the gist with the new values, here you can see the diff: https://gist.github.com/oxc/eb7bbae8acd5639274b2c62338b4f588/revisions

Thanks!

[andrew-shpak]

I am trying to add new value by using intent from useForm, but my ide show me type error - Type string is not assignable to type Partial<any>. Is this issue on ide/code side ?

 intent.insert({
                          name: name,
                          index: index + 1,
                          defaultValue: "",
                        });
                        

[edmundhung]

Looks like a bug on the types. I will look into it tomorrow. Thanks!

[andrew-shpak]

Looks like a bug on the types. I will look into it tomorrow. Thanks!

The same bug I find with intent.update as well.
Apart of it, I am trying reset filters form with predefined state. State is stored in url. So when I reset form I get not empty values but initial state.
As a workaround I am using intent.update for fields reset to empty state