`field.props.onInput` does not work with `v.number` schema.

[ashtonjurgens]

I have use valibot's number schema, and have an input component connected to it with type="number". The problem is, the value is always a string, which cannot be equal to a number (123 !== "123").

I think the getElementInput function, which is responsible for coercing the element.value according to the type attribute, should give special handling to the "number" type. If it would coerce the string to a number, then spreading field.props would be usable with number schemas.

[fabian-hiller]

Hey, it is true that this is not yet natively supported. It would require getElementInput to somehow know about the v.number() schema. We may implement it in the long run. I think I haven't implemented it as it is not yet clear if we want to support other schema libraries besides Valibot for our v1 release.

In the meantime, I recommend using v.pipe(v.string(), v.toNumber(), ...) you can also use other actions like v.decimal() or v.minValue().

[ashtonjurgens]

I am using this kind of pipe, the issue is that the isDirty check will always be true, if the initial input is a number, because onInput will set a string. 123 !== "123"

[fabian-hiller]

What if you convert the initial input to a string? Another solution could be to capture the input manually with setInput to be able to use a number directly.

[ashtonjurgens]

Thanks, I went with the setInput solution.

On the same same note, it seems Date objects aren't supported. I wonder if you would consider adding plugin-like capabilities for this kind of thing, meaning you customize how isDirty is calculated.

For me, if there's no way to customize this, then I'm not sure I can directly reuse my valibot schemas for forms, since I use date schemas and probably other unsupported schemas. I would have to make new schemas where I replace unsupported schemas with strings schemas.

[fabian-hiller]

Thank you for your feedback! Supporting specific data types is support in our Vue version but the other frameworks have no native way to hook into what <input /> returns but this is solvable and we will probably look into it before v1. We could just try to read the schema and return the correct type or allow users to apply a transformation before the input is captured.

[ashtonjurgens]

I'm having the same concerns you mentioned in #2. I can think of ways this could work very well with Valibot, but then you run into having to replicate this across every popular schema lib.

I would solve all these problems like so:

Create a new interface, Engine, which handles some of the nuanced behavior of formisch.

For example, when formisch wants to set isDirty, it will use engine.getIsDirty(previous, current) to resolve the correct value.

We can slowly add methods into Engine, as they are requested by the community. This also solves the problem of supporting difficult DX features in multiple schema libraries, because we can let Engine handle the nuanced parts, and build "engines" for each schema library.

User code example

createForm({
   schema: MySchema,
   engine: {
     // plain engine config...
   },
   // OR
   engine: createValibotEngine({
      // My customizations go here...
   })
})

Of course, if you don't pass engine there will be some default behavior. Maybe it will detect what schema library you use, and use that engine.

I'm happy to start experimenting with this concept in a fork, unless you think there is a better path forward.

[fabian-hiller]

I'm not sure if this is the right approach, but I haven't thought about it much. First, I would brainstorm different solutions before committing to one.

Here are a few ideas on how we can solve the data type problem:

1. Ask the user to pass an optional type prop to useField and <Field /> (with 'string' as the default)

   • This is the approach we used in Modular Forms
   • The advantage is that it always works reliably
   • The downside is that the user has to specify the type twice when it is not a string

2. Infer the type from the .schema prop that we store internally for every field

   • The schema acts as the single source of truth → excellent developer experience (DX)
   • The drawback is that it would require, for example, a resolveType function for each schema library adapter if we want to support additional schema libraries in the future

3. Allow the user to provide a transformation function that runs before the value is captured

   • This likely results in the smallest bundle size and the greatest flexibility
   • However, it requires a bit more effort from the user
   • We could provided pre-build transformation functions for common data types

What do you think is best?