Return value from parse validation.

[lhapaipai]

Re-Hi,

When we parse formData with parseWithZod we get a Submission discriminated Union type depending on the status success or error.

// packages/conform-dom/submission.ts
export type Submission<Schema, FormError = string[], FormValue = Schema> =
	| {
			status: 'success';
			payload: Record<string, SubmissionPayload<FormDataEntryValue>>;
			value: FormValue;
			reply(options?: ReplyOptions<FormError>): SubmissionResult<FormError>;
	  }
	| {
			status: 'error' | undefined;
			payload: Record<string, SubmissionPayload<FormDataEntryValue>>;
			error: Record<string, FormError | null> | null;
			reply(options?: ReplyOptions<FormError>): SubmissionResult<FormError>;
	  };

when zod parse the input with schema.safeParse he returns data coerced and we can use that in the value property.

Actually when we validate a submission the value is not available even if validation is successfull.

Here you can find some test I write wich highlights my issue

import { parseWithZod } from "@conform-to/zod";
import { expect, test } from "vitest";
import { z } from "zod";

function createFormData(
  entries: Array<[string, FormDataEntryValue]>
): FormData {
  const formData = new FormData();

  for (const [name, value] of entries) {
    formData.append(name, value);
  }

  return formData;
}

test("parseWithZod()", () => {
  const schema = z.object({
    title: z.string(),
  });
  const formDataValidSubmission = createFormData([["title", "Hello"]]);

  expect(parseWithZod(formDataValidSubmission, { schema }))
    .toMatchInlineSnapshot(`
    {
      "payload": {
        "title": "Hello",
      },
      "reply": [Function],
      "status": "success",
      "value": {          // ok we have a value because it is a submission
        "title": "Hello",
      },
    }
  `);

  const formDataValidValidation = createFormData([
    ["title", "Hello"],
    [
      "__intent__",
      JSON.stringify({
        type: "validate",
        payload: { name: "title" },
      }),
    ],
  ]);
  expect(parseWithZod(formDataValidValidation, { schema }))
    .toMatchInlineSnapshot(`
      {
        "error": {},         // we have no error so zod have returned a data 
        "payload": {         // but we don't have this zod data as value because it is a validation.
          "title": "Hello",
        },
        "reply": [Function],
        "status": undefined, // status is undefined, it is a validation
      }
    `);
});

the logic is in this line :

conform/packages/conform-dom/submission.ts

Line 225 in 077215b

if (context.intent || !context.value || context.error) {

I wanted to know if it can be possible to make accessible the value if this value is available by a successfull parse even if it is a validation ?

// packages/conform-dom/submission.ts
export function createSubmission<FormValue, FormError>(
	context: SubmissionContext<FormValue, FormError>,
): Submission<FormValue, FormError> {
	if (context.intent || !context.value || context.error) {
		return {
			status: !context.intent ? 'error' : undefined,
			payload: context.payload,
			error: typeof context.error !== 'undefined' ? context.error : {},
+			value: context.value,
			reply(options) {
				return replySubmission(context, options);
			},
		};
	}

	return {
		status: 'success',
		payload: context.payload,
		value: context.value,
		reply(options) {
			return replySubmission(context, options);
		},
	};
}

Use case

I have a form and I have a preview component who need to be updated in real time with validated data.

Thank you very much :-)

[chimame]

Thank you for your interest in Conform.

The behavior of intent is as expected. I don't understand it. Can you show me a sample code of how you want to use form and Conform?

[lhapaipai]

Hi @chimame ,
thank you for your response !
I've implemented a minimal example on the value-on-validate branch
https://github.com/lhapaipai/conform-discussions/tree/value-on-validate

I understand that what I ask is not the expected behavior of intent.
But I think the example can be interesting.
without a lot of work you can implement a preview of a uncontrolled form.
As expected the PostForm component never re-renders
I've added a highlightElement to show you when rerender occurs.

please use pnpm as packageManager because I have patched the @conform-to/dom.
https://github.com/lhapaipai/conform-discussions/blob/value-on-validate/patches/%40conform-to__dom%401.3.0.patch

Don't hesitate if you have any questions. And also if you see another way to achieve the same result.

[lhapaipai]

Hi @chimame,
Thank you for your response.
Effectively there is a difference and that's because there is a difference that y would prefer the value property.
indeed in my example, using payload or value changes absolutely nothing. but now imagine that I add a transform method to my schema?
With a boolean there is a lot of cases to control and it is precisely for all of this that we use @conform-to/zod.

Actually if validation is successfull, zod with safeParse has computed the value but parseWithZod choose not to return this property and I wonder why ?

• it's not for performance reason because value is already computed
• from what I've read, conform-to verify the undefined value of status property in his logic to determine if it is a submission or a validation. so I don't think adding this property would break the logic

Maybe there is something in the logic which I am not aware of ?

[chimame]

There is a big difference between payload and value in the return value.

payload is an object version of the input FormData. Therefore, all values ​​are stored as strings. In other words, they are the input values ​​themselves.

value is stored when validation is successful and the value is converted to the type defined in the schema. This stores data that can be obtained when validation is successful with safeParse in Zod. If validation is not successful with Zod, data cannot be obtained, and therefore value cannot be stored.

Can you see the difference between payload and value in the code below?

const schema = z.object({
  name: z.string(),
  age: z.number()
})

const formData = new FormData()
formData.append('name', 'test name')
formData.append('age', '30') // Numbers cannot be stored in FormData.

const submission = parseWithZod(formData, { schema: postSchema })
// submission => {
//   payload: { name: 'test name', age: '30' },
//   value: { name: 'test name', age: 30 }, It has been converted to a number.
// }

It is not possible to store the data before conversion in the value property even if validation is not successful, as this would cause a type inconsistency. This is because value stores object data of the type defined in the schema.

Also, looking at the sample code you created, shouldValidate specifies onInput, but this appears to be because you want to retrieve FormData, not validate the data as it is entered. Conform updates the state at the time of submission, that is, validation, so this is a different purpose from Conform.

In other words, if you want to retrieve data as it is being entered, it is best to use onChange for each input.

[lhapaipai]

For the first part I'm totally agree with you

payload is an object version of the input FormData. Therefore, all values ​​are stored as strings. In other words, they are the input values ​​themselves.

value is stored when validation is successful and the value is converted to the type defined in the schema. This stores data that can be obtained when validation is successful with safeParse in Zod. If validation is not successful with Zod, data cannot be obtained, and therefore value cannot be stored.

Can you see the difference between payload and value in the code below?

const schema = z.object({
name: z.string(),
age: z.number()
})

const formData = new FormData()
formData.append('name', 'test name')
formData.append('age', '30') // Numbers cannot be stored in FormData.

const submission = parseWithZod(formData, { schema: postSchema })
// submission => {
// payload: { name: 'test name', age: '30' },
// value: { name: 'test name', age: 30 }, It has been converted to a number.
// }

I think I expressed myself badly, but I wanted to say in my words exactly the same thing as you

Effectively there is a difference and that's because there is a difference that y would prefer the value property.
indeed in my example, using payload or value changes absolutely nothing. but now imagine that I add a transform method to my schema?
With a boolean there is a lot of cases to control and it is precisely for all of this that we use @conform-to/zod.

I meant that in my example we didn't see the difference but I understood the nuance.

To be clearer I should write my hook

const [lastValidPost, setLastValidPost] = useState<Post>(post);

and it is indeed a Post type that is expected and not a FormValue<Post> type

Also, looking at the sample code you created, shouldValidate specifies onInput, but this appears to be because you want to retrieve FormData, not validate the data as it is entered. Conform updates the state at the time of submission, that is, validation, so this is a different purpose from Conform.

My intention is to find a value but in the most reactive way possible not FormData. where I have to be clear, FormData does not interest me, as not usable.

My use case is in a crud for editing an article where all the fields have already been pre-filled and valid. I want (if and only if what is changed is valid) to display the pre-rendered version of the post (which assumes a Post type) and I want this to react to the end user's input. that's why I use shouldValidate: "onInput".

I imagine this is not the most common case. Hoping to have been able to give you all the information to judge

conform.mp4

[chimame]

Thank you for the detailed explanation. I finally understand it.
This is a temporary code, but is this the code that doesn't need to be patched?

import { getZodConstraint, parseWithZod, unstable_coerceFormValue as coerceFormValue } from "@conform-to/zod";

function PostFormComponent({ setPreviewPost }: Props) {
  const [form, fields] = useForm({
    defaultValue: post,
    constraint: getZodConstraint(postSchema),
    onValidate({ formData }) {
      const submission = parseWithZod(formData, { schema: postSchema });

      if (submission.status === 'success') {
        setPreviewPost((lastPreview) => ({
          ...lastPreview,
          ...submission.value,
        }));
      }

      if (submission.status === undefined) {
        const schema = coerceFormValue(postSchema)
        const result = schema.safeParse(submission.payload);
        if (result.success) {
          setPreviewPost((lastPreview) => ({
            ...lastPreview,
            ...result.data,
          }));
        }
      }

      console.log(submission);
      return submission;
    },
    shouldValidate: "onInput",
  });

  ...
}

[lhapaipai]

Thank you @Chimane for taking the time to read this.
Your code works perfectly, doesn't require any patches, and shows that we're thinking the same thing.

But as you know (better than I do, given your work on the project), in the case of a validation the work is done twice. because the value is already computed by the schema.safeParse in the parseWithZod function.

Like you can see in this extract (createSubmission is called with result of safeParse inside the parseWithZod function.

conform/packages/conform-dom/submission.ts

Line 222 in c064790

export function createSubmission<FormValue, FormError>(

// packages/conform-dom/submission.ts
export function createSubmission<FormValue, FormError>(
	context: SubmissionContext<FormValue, FormError>,
): Submission<FormValue, FormError> {


	if (context.intent || !context.value || context.error) {
                // in the case of a validation with error:
                //  -  context.intent is defined
                //  -  context.error is defined
                //  -  context.value is not defined
                // in the case of a validation with success: 
                //  -  context.intent is defined
                //  -  context.value IS ALSO ALREADY PRESENT
                //     why not explicitly ALREADY return it?
		return {
                        // it is the status value who is checked to differenciate
                        // validation with error vs validation without error
			status: !context.intent ? 'error' : undefined,
			payload: context.payload,
			error: typeof context.error !== 'undefined' ? context.error : {},
			reply(options) {
				return replySubmission(context, options);
			},
		};
	}

	return {
		status: 'success',
		payload: context.payload,
		value: context.value,
		reply(options) {
			return replySubmission(context, options);
		},
	};
}

In fact, I don't think there is any breaking change. And it seems to me that we have everything to gain from it.

hence my previous sentence

from what I've read, conform-to verify the undefined value of status property in his logic to determine if it is a submission or a validation. so I don't think adding this property would break the logic

But of course I know how delicate interventions can be, especially when they are requested by outsiders like me who probably don't have a complete vision of the project. That's why I opened this discussion.

It's up to you to decide. but on the other hand I would be interested to understand why this modification is not suitable 🙏🙏