null as input and default value, but not output

[lukasvice]

I'd like to have a schema with the following behavior (e.g. for a number input field):

Input type: number | null
Output type: number
Default: null

So I tried the following:

• v.nullable(v.number()) -> Output type is number | null; Default is undefined
• v.nullable(v.number(), 0) -> Default is 0
• I also tried v.transform but I didn't find a way to do it.

Thanks for your advice!

[fabian-hiller]

Where does the number output come from if someone passes null as input and the default should also be null? If the default is null, I see no way to turn that into a number for the output.

[dboune]

Thanks, @fabian-hiller! I appreciate your taking the time to read these discussion threads, seriously consider the needs of your users, and provide your input. I'm not alone in feeling very positive about your approach.

A DeepNullable utility could also work when the entire form comprises only Select components or other components accepting null as "empty". I would need to be targeted. Not every field should allow null input, even as an acceptable invalid input.

The nullableInput, emptyInput, optionalInput, and nullishInput I've added for myself work well enough to create a clean, simple, unified experience. It's already saved me many headaches, and it's very nice that this can be done easily.

I can only agree that this need is specific to the concept of form validation, with additional specificity for React and component libraries like MUI (Joy is an official variant of MUI) and the usage pattern of react-hook-form, which are currently among the most commonly used. Your user base will likely be composed of a fair number of people using this combination and some portion of those confronting similar situations. As developers, we are all looking for ways to simplify our work while maintaining quality.

For the sake of conversation, Valibot presents itself as a schema library offering the ability to "Validate unknown data." Indeed, the parse method takes unknown as input. Valibot is a schema library, but I also viewed it as a validation library, including schema and value validation, so I generally expect the potential for Input to be less strict than the definition and expected output. As I said before, I adore the type inference capabilities tools like Valibot provide and what that affords me as a developer in a TypeScript environment.

My queries seem to center around my misuse (or unexpected creative use 😁), but from the perspective of form validation (recognizing that another situation may have a different set of needs), I took the Input type as the type to be used for expected inputs to my form, which for a form must include acceptable invalid input as a core concept due to the nature of a form, even where we don't want to assign a default, fallback, or transform. Output requirements are naturally more strict, even considering schema validation.

On the Infer types page, Valibot states...

You are probably interested in input type only in special cases. I recommend you to use the output type in most cases.

At least in the form validation process, this is that special case for me! I can imagine other instances where we want to assert schema via typing first (which I also need to do here, but with more flexibility) and then primarily validate values. However, if I am in a position where I cannot fully trust the schema type, then utilizing Input is rather dangerous.

For that polar opposite, if I were using Valibot to validate an HTTP POST body, I'd be uninterested in Input as I couldn't trust any assertion it makes. Handling that kind of input as unknown is the only appropriate way to view it until the schema can be validated.

Thanks for creating Valibot! I was using TypeBox everywhere previously, and while it is a stellar tool, I'm not using its JSON schema capabilities other than value validation, and it's quite a bit more work to process and customize the error messages it provides when considering form validation in particular. Valibot offers a sensible API with excellent OOTB capabilities, making it an easy choice. It might interest you that the TypeBox Workbench convinced me that Valibot was the right choice, as my interfaces that compiled cleanly to TypeBox code also compiled cleanly to Valibot code but not to any other supported tool.

[fabian-hiller]

Thank you for your detailed answer and your kind words. This kind of feedback is very important for further development of Valibot. I found two more solutions that might work for you.

In the first one you keep your schema as it is (without nullableInput). Also, you do not provide any default values to the form. This way the value of your field will be undefined. When passing the value to your MUI component, write the following value ?? null to prevent passing an undefined value. If you try this, let me know if it works.

The other solution requires a new function called input that I could add to Valibot. input takes a schema as first argument and allows to transform it's input type via it's generics. I have not investigated the implementation, but this is what the API could look like.

import * as v from 'valibot';

const RepeatSchema = v.input<null>(v.picklist(['daily', 'weekly', 'monthly']));

type RepeatInput = v.Input<typeof RepeatSchema>; // "daily" | "weekly" | "monthly" | null
type RepeatOutput = v.Output<typeof RepeatSchema>; // "daily" | "weekly" | "monthly"

[dboune]

Defining the schema without any notion of optional, nullable, or nullish, the answer is a partial yes. It's a valid suggestion.

From a defensive programming perspective, this could be a good idea. However, one has to be very careful to handle all possible cases.. we may not be able to rely on || because a numeric zero could be a valid value, but ?? may not either be perfect as we may need to cover empty string for some cases, so our tests might become complex and prone to requiring frequent customization thereby making it difficult to componentize frequently used inputs. I've tried to avoid doing too much with value and onChange this way as it tends to be error-prone or requires too much situation-dependent variation.

As a form becomes more complex, such as dealing with variants, create and edit modes, etc., we start to face more challenges. It may indeed become necessary to utilize Partial too broadly, which can lead to confusion later on.

Additionally, if using Eslint with typescript-eslint/strict-type-checked we will encounter errors testing for values not included in the type, which I realize is a choice. I prefer to be very explicit end to end.

So, the input function option with the flexible type generic seems perfect for my needs. It allows me to be very explicit about what constitutes an acceptable invalid input, which greatly simplifies ensuring form inputs meet component requirements, whatever those might happen to be. This also helps a great deal when dealing with database output where null is a common value, and we need to make sure that values are transformed appropriately.

[fabian-hiller]

Thanks for your feedback. Feel free to create an issue for an input and maybe an output function. I am not sure if I want to add such functionality, but the issue will give us a dedicated space to discuss and get opinions from other developers.

[TeChn4K]

I was looking for this exact discussion all over existing validation/schema libraries! Thanks I'm not alone anymore!

My needs are very similar :

• initialize form inputs with null values (fields are empty at start)
• some fields are optionals, but some others required
• have an "all nullable inputs" schema (for react-hook-form defaultValues & watch)
• have an "strict output" schema (for onSubmit)

I'll take this discussion further for this use case. Thanks all.