Replies: 2 comments 1 reply
|
Hi, For issue 1, customize only handles coercion (deserialisation), so it does not have enough information to decide how the data should be serialised. I do understand the pain of having to do this manually though. What you are probably looking for is a schema-based serializer and deserializer. That is not impossible, but it would require fairly extensive schema introspection, and it is hard to support every kind of schema consistently. It is definitely worth exploring, but it would take a non-trivial amount of effort. A simpler alternative could be to extend Conform’s naming conventions to support automatic JSON serialisation, for example: We could then extend useControl to accept more complex data structures and serialise them as JSON when it detects a name pattern that expects JSON. The downside is that this pushes more setup and responsibility onto the developer. For issue 2, I agree this looks like a bug. It should accept a string as-is for this use case. |
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Hi developers!
I noticed the very interesting
customizeoption forcoerceFormValuebut I encounter some unexpected results when I try to use it in my application.Context
I have a file Picker field and I want to use it in a
MediaFieldcomponent. I simulate the file picker with a simple<button>that callscontrol.changewhen we click on it.I encounter two issues:
useFormdefaultValueoptionReproduction
Issues
Issue 1: Data preparation required
I need to manually prepare the data from the loader by stringifying the object:
Without this preparation, the form doesn't work correctly even though I've set up the
customizefunction to handle JSON parsing.Issue 2: TypeScript type error
When using the prepared data as
defaultValue, I get a TypeScript error because:mediato be of typeMedia(object)Question
Is there a better way to handle stringified JSON values with the
customizeoption? I expected that:customizefunction would allow me to pass the original object (not stringified) asdefaultValueExpected behavior: Being able to pass the original object structure from the loader directly to
defaultValue, and having thecustomizefunction handle the stringification internally when needed.Current behavior: I need to manually stringify the data AND deal with TypeScript type mismatches.
Am I using the
customizeoption incorrectly, or is this the intended pattern?Idea
Related to this example and to this discussion : #1135
I'm wondering if a
prepareFromZodSchemautilitary function could be interesting ?Thanks for your help!
All reactions