You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Now it turns out that the library insuring against runtime errors doesn't help us. I think default must respect validations.
console.log(v.string().assert(value=>value.length>10).default(1).parse(undefined));// 1console.log(v.number().default(1).parse());// 1// Imagine that i have `userRole` in `schemas.ts` and in other file i adding fallback if value is undefined. Then i change union literals, but default in other file keeps old value.constuserRole=v.union(v.literal('admin'),v.literal('user')).default('waiter');console.log(userRole.try(undefined/* runtime value that was OK previously */));
The purpose of default is to allow undefined (or a missing value), and to replace undefined with a default value. It is comparable to the following scenarios elsewhere in JavaScript/TypeScript:
const{ value=1}={value: undefined};// value is now 1functionf(value=1){returnvalue;}f();// 1f(undefined);// 1
Like with all other Type methods (.optional(), .map(), ...) the order matters. If you want the type assertions to apply to .default() then add the type assertions. It would be more surprising if .default() was the exception. In itself it keeps the type safety, as it adds the default value's type to the output types.
My concern is that anything can be put in it and the value will not be validated according to the given rules.
What is it for and is it needed now?
The text was updated successfully, but these errors were encountered: