v.optional after transform to undefined

[IlyaSemenov]

I'd like to create a schema for parsing values that are either strings (in fact, only "") or numbers. For context, this type of data is coming from Vue <input v-model.number="field">.

For numbers, I want to keep them, for "", I'd like to get undefined.

This is what I have currently:

export function inputNumber() {
  return v.union([
    v.pipe(v.literal(""), v.transform(() => undefined)),
    v.number(),
  ])
}

Then I can use it like this:

v.object({
  requiredNumber: v.pipe(inputNumber(), v.custom(value => value !== undefined, "Required.")),
  optionalNumber: inputNumber(),
})

This kinda works, but the optional/non-optional handling is reversed compared to the built-in schemas. Also, the inferred return type for requiredNumber is number | undefined which is not correct.

All and all, I'd like the end-user code to be something more like:

v.object({
  requiredNumber: inputNumber2(), // allow only number values
  optionalNumber: v.optional(inputNumber2()), // allow number or "" in values, return undefined for ""
})

How do I build inputNumber2 for the case above?

[fabian-hiller]

Can you provide a playground link that reproduces the problem?

[IlyaSemenov]

Sure, here's the playground.

Just to clarify, it's not a problem in Valibot, it's my lack of understanding on how to organize things for this use case.

[fabian-hiller]

Instead of custom you should use check. We renamed custom to check in v0.31.0.

Here is how I would write this schema. Try it out in this playground.

import * as v from 'valibot';

const Schema = v.object({
  requiredNumber: v.number(),
  optionalNumber: v.union([
    v.pipe(
      v.literal(''),
      v.transform(() => undefined),
    ),
    v.number(),
  ]),
});

[fabian-hiller]

And if you want to reuse the OptionalNumberSchema I would write it this way:

import * as v from 'valibot';

const OptionalNumberSchema = v.union([
  v.pipe(
    v.literal(''),
    v.transform(() => undefined),
  ),
  v.number(),
]);

const ObjectSchema = v.object({
  requiredNumber: v.number(),
  optionalNumber: OptionalNumberSchema,
});

[IlyaSemenov]

I appreciate your help, but that's not really what I was asking for. Granted, that code works and that's similar to how I ended up doing on my own (I didn't update the question because that approach wasn't really a solution, but mere a workaround).

The problem with the approach above is inconsistency. Consider the code:

import * as v from 'valibot';

const OptionalNumberSchema = v.union([ ... ])

const ObjectSchema = v.object({
  requiredString: v.string(), // will emit "Must be defined" on missing input
  optionalString: v.optional(v.string()),
  requiredBool: v.boolean(), // will emit "Must be defined" on missing input
  optionalBool: v.optional(v.boolean()),
  requiredInputTypeNumber: v.number(), // will emit "Expected number, got string" on missing input
  optionalInputTypeNumber: OptionalNumberSchema, // how so this is very different from the other optional fields?
});

Do you see how this is not aligned? That means:

• extra mental burden on schema authors and readers
• not being able to reuse the new schema in higher level functions due to non-uniformity

So my question is not how to validate "optional numbers", that I can do.

My question was — as stated in the opening post — how (if that is possible at all) build a field schema handling such input that can be used consistently with the other fields schemas handling different input? So in the code above, it would somehow become:

const ObjectSchema = v.object({
  requiredString: v.string(),
  optionalString: v.optional(v.string()),
  requiredBool: v.boolean(),
  optionalBool: v.optional(v.boolean()),
  requiredInputTypeNumber: inputTypeNumber(), // uniformly with the above
  optionalInputTypeNumber: v.optional(inputTypeNumber()), // uniformly with the above
});

or that I can provide to some helpers that build a wrapping schema with a loop.

I realize that's apparently not directly possible as .optional is quite naive and means it accepts undefined and strings are not undefined, so not much to do here.

However, I imagine there could be some architectural approach making this possible; the use case comes from the real world.
Like some kind of "pretransform" hooks that will be called by the outer schema prior to the validation (just making it up...not much thought given).

[fabian-hiller]

Is your goal a reusable schema function similar to optional that accepts an empty string (with a transformation to undefined) besides the data type of the schema passed as the first argument?