default value

[tzezar]

I'm leaving this as if someone is also looking for how to set the default value, and under the keyword "default value valibot" nothing else would pop up for them. It's done with v.optional. Finding this took me significantly longer than it should have.

const schema = v.object({
      keepStock: v.optional(v.boolean(), true),
});

[fabian-hiller]

More details here: https://valibot.dev/guides/optionals/#default-values

[MentalGear]

This is really hard to find and hampers overall adaption of Valibot. Spend several minutes going over the docs using search, and only the useless type defintion (https://valibot.dev/api/Default/) turned up, and I had to google and searching github for something that is a basic func.

Please rethink adding a .default() method as this most closely resembles how other libraries handle this, especially since you mention having your API modelled after Zod. Or at the very least have the right page turn up as the first when searching for default in the docs.

[yolio2003]

I agree not to add default values to optional, optional with default is a NerverOptional...

However:

i think default can not be covered by optional or nullable ..., for example :

const VariantSchema = v.variant('type', [
  v.object({
    type: v.literal('email'),
    email: v.pipe(v.string(), v.email(), v.default('xxx@gmail.com')),
  }),
  v.object({
    type: v.literal('url'),
    url: v.pipe(v.string(), v.url()),
  }),
  v.object({
    type: v.literal('date'),
    date: v.pipe(v.string(), v.isoDate()),
  }),
]);

// with default we can only parse `type` field
const val = VariantSchema.parse({
  type: 'email'
})
// val with be { type: 'email', email: 'xxx@gmai.com' }

This is definitely a different semantics from "optional".
infact, this is the only reason i can not replace zod with valibot
cc @fabian-hiller

[fabian-hiller]

Why don't you use v.pipe(v.optional(v.string(), 'xxx@gmail.com'), v.email())?

[yolio2003]

i tried this, looks like it works. thx!
Obviously, optional + defaultValue = default, although not so straightforward.

[bakura10]

@fabian-hiller , I am also having a hard time understanding the logic due to the lack of default. Interestingly, I have this use case:

v.object({
  name: v.pipe(v.optional(v.string(), ''), v.nonEmpty("Name can't be blank"), v.maxLength(255)),
  type: v.pipe(v.optional(v.picklist(['boolean', 'multi_line_text_field', 'list.single_line_text_field'], 'Type is required'), ''))
});

I'm not sure to understand why, but for the picklist, the default value triggers a TypeScript error (but not on the name), however it properly returns the empty string when using the getDefaults() function. Do you have an idea of why?

[fabian-hiller]

This is because an empty string it not a valid option of the picklist.

[bakura10]

@fabian-hiller one other rather unintuitive behavior I've found was that I have a required data, but I want to give it a default value to be used with getDefaults(). The problem is that the InferOutput will now add "myType | undefined", as it is marked as optional. You therefore has to wrap it around a nonOptional to remove the undefined. If adding a v.default() is not possible, would it be possible maybe to consider adding a second parameter to nonOptional, to set a value that will be used with getDefaults ?

[fabian-hiller]

Can you share a minimal playground with a reproduction?

[bakura10]

I found the issue, the correct way was this:

type: v.pipe(v.optional(v.string(), ''), v.picklist(['boolean', 'multi_line_text_field', 'list.single_line_text_field'], 'Type is required')),

I'm still getting my head around this, I think something like that would be more intuitive:

type: v.pipe(v.picklist(['boolean', 'multi_line_text_field', 'list.single_line_text_field'], 'Type is required'), v.default('')),

[fabian-hiller]

True, but it would force us to check the entire pipe for v.default(''), which would compromise performance and it's probably very hard to get the types in the pipeline right.

[bakura10]

Hello @fabian-hiller , I'm sorry for pinging you again on this, but the more I use this API (optional) the more I feel it is an incorrect abstraction. In some cases, I have a schema where a value is required (in the sense that I must receive a value complying with the schema), but where I still need a default value (the getDefaults being, in my opinion, the selling point of Valibot due to how easy it makes to work with form). In some cases, I have a value that is effectively optional (in the sense that the user can output nothing or an empty string).

To use this schema, this ultimately translate as this:

const Schema = v.object({
  required: v.pipe(v.optional(v.string(), ''), v.email()),
  optional: v.optional(v.union([v.literal(''), v.pipe(v.string(), v.email())]), ''),
});

What confuses me a lot is how both actually have something called "optional" while, in the first case, it is actually not optional. There is something conceptually wrong in the naming that consistently make me think twice in the order I am doing thing (and when I have to constantly think about what I'm doing, it often means that the API is incorrect somewhere :D). Something that is not optional should not have something called optional, in my opinion.

This looks much more logical and remove confusion: this shows at first glance that the required field is not optional:

const Schema = v.object({
  required: v.default(v.pipe(v.string(), v.email()), ''),
  optional: v.optional(v.union([v.literal(''), v.pipe(v.string(), v.email())]), ''),
});

[fabian-hiller]

Thank you for your feedback! What are you using the default value for? If a value is required, the default value will never be "used". For example, if you need a default value for form fields, it seems more appropriate to treat this as metadata. Perhaps we should therefore provide a default metadata action, similar to our title and description action. We could then build a new getDefaults method on top, similar to our getMetadata method. If we like this idea, we need to address the possible naming conflict before we can start implementing it.

[bakura10]

I actually use the default to feed the forms. The library I use requires all controlled inputs to have a string, so being able to provide a default string value for building the form state is the reason I use this :).

[fabian-hiller]

If you only need an empty string for each field, you could write a function that reads the schema object (via schema.entries) and outputs a new object containing an empty string for each value. While I think this is something that the schema library should probably fix, I am also open to discussing a new default metadata API.

[bakura10]

May I ask, according to you, what is actually the use case of the second value of optional?

[fabian-hiller]

Providing a default value that the schemas uses as a fallback value if no value is provided. It is tightly coupled to the schema execution and is therefore not directly intended to be used as metadata information.