InferOutput not including fallbacks

[CanRau]

Hey I'm a little confused while improving our schemas as I realized that InferOutput doesn't include fallbacks, if the type can be nullish/optional/nullable etc.

As stated in the docs

This means that no issues will be returned when using fallback and the schema will always return an output.

So I'd expect the InferOutput<schema> type to be of that resulting type.

As I'm using it mostly to parse API inputs to pass into our DB (using Kysely) it correctly complaints that certain fields don't accept null/undefined values, tho the parsed.output shouldn't be empty as I provided fallbacks where it makes sense, the idea being that I don't have to provide certain fields to get a default fallback generated.

I realized that I can move most of those types to just be optional or nullish tho shouldn't any of those wrapped in a fallback still provide a defined output type?

[fabian-hiller]

Hey 👋 thank you for reaching out! Can you provide a minimal example, e.g. via our playground?

[CanRau]

sure

At least this is what I'd expect

[CanRau]

Added isFalse which has a fallback but without nullish, which makes input not work as desired as isFalse will be required according to types.

[fabian-hiller]

I think there is a misunderstanding here. What you are looking for is the default value of optional, nullable and nullish. Have a look at this playground and the optionals guide in our docs.

[CanRau]

Though why shouldn't I be able to compose fallback with one of the optionals?

Or different question how/when is fallback meant to be used?

[fabian-hiller]

optional, nullable, and nullish are schemas that use the default value as the schema's input when the original input is undefined or null. fallback works differently. fallback is a method that changes the behavior of a schema by returning the fallback value as output whenever the schema returns an issue. Therefore, your schema will never return an issue when fallback is used.

So in simple words... the default value is used as the input of the schema when there is "no input", and the fallback value is used as the output of the schema when the validation fails. Therefore, a default value can change the type signature because we know that there will always be a value, but fallback has no effect on the type signature because any valid input is accepted and does not trigger the fallback value.

[CanRau]

because any valid input is accepted and does not trigger the fallback value.

And therefore also ensuring that there will always be a value in the output right?

So InferOutput could (and I think should) reflect that fallback overrides the optional type, or at least I still don't understand why it shouldn't and what the benefit is?

To me fallback is pretty much the same as all other optionals just "more insisting" on continuing the happy path "no matter what" and you combine it with one of the optionals to optionally reflect in the input type that you don't have to provide a value...

[fabian-hiller]

And therefore also ensuring that there will always be a value in the output right?

No, because undefined is a valid value when optional is used inside fallback. So it will not trigger the fallback value in this case. Check this playground.

[CanRau]

Uuuh hadn't considered undefined as a fallback value 😅

And inferring that doesn't work or would be too much? Like if the fallback value is not undefined have the output type be non optional 🤔

[fabian-hiller]

As shown in the provided playground, if undefined is the input, then undefined is also the output as the fallback value is not triggerd. Removing undefined from the type signature would be a bug.

Only default values can affect the output type, because they can ensure that e.g. undefined is never returned, fallback values work differently, as described above.

[fabian-hiller]

Has this issue been resolved or do you have any other questions or ideas for improvement?