submission.reply() uses context.payload and not context.value

[Pouet--]

Hello,

I would like to know why is conform serializing context.payload in the reply() function, as detailed here

I found this when my application told me that a html <select> element should have a defaultValue as an array if it is of type multiple.

So I found there is a difference between :

• payload: { foo: [ 'not_processed', 'wait_processing' ], bar: '1' }
• value: { foo: [ 'not_processed', 'wait_processing' ], bar: [ 1 ] }

After this, the initialValue of my form will be the serialized version of payload, so my number[] becomes number.

@edmundhung Could you quickly explain the difference and the choice you've made here ? Thank you in advance !

[edmundhung]

This is a limitation of the current naming conventions we used as there is no way we can know the form data entry is an array until I see the second entry with the same name. This is why your payload might look like this if there is only one item selected. Whereas value likely used the information from the zod schema to coerce it to an array automatically.

I have thought about supporting an array notation for this case, e.g. files[]. But there is another challenge on the configuration as I don't always know whether it is a multiple select or not meaning I couldn't infer a name for you.

[Pouet--]

I understand the difference as the payload comes from the url search params and indeed we can not guess what type each parameter should be.

But why can't you return the serialized version of value ? Isn't it always defined in case of a succesful submission ?

[edmundhung]

Maybe I could? But I think there are few things to consider:

• value is not always available. We have a value only if the schema parsed successfully
• value could have a completely different shape if you transform it in the schema
• Re-serializing it might end up with a different value then what we received

[Pouet--]

My first guess was to return value and to use payload as a fallback, but indeed there could be big changes due to transform() in schemas, and re-serialization, I did not think about it.
Thanks for your thoughts.

[edmundhung]

This is definitely something I want to revisit in the next version. Maybe it is not a bad idea to use the array notation and just force people to either let useForm hook know about the multiple attribute or not to use the inferred name...?

@Pouet-- i have been working on the next version and I would love to get your feedback. If you are interested, feel free to ping me on twitter (_edmundhung) or discord (edmundhung)