-
-
Notifications
You must be signed in to change notification settings - Fork 14
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
.min
or .destruct
on .construct
ed fall back to main type
#79
Comments
For anyone with a similar problem: For now, I'm falling back to export const stringOrObjectWithKey = unknown.transform((input: any | string | { key: string }) => {
if (typeof input === 'string') return input;
if (input && typeof input.key === 'string') return input.key;
throw new TypeError(`Expected string or { key: string }: "${input}"`);
}, StringValidator) as ValidatorProxy<StringValidator<[string | { key: string }]>>; which works as expected. But in the long run, it would be nice if PS: export const stringOrObjectWithKey = Schema.either(string, Schema({ key: string })).transform(
(input) => (typeof input === 'string' ? input : input.key),
StringValidator
) as ValidatorProxy<StringValidator<[string | { key: string }]>>; also seems to do the trick and leaves a bit more work to |
It's impossible to detect on runtime what's the right chain methods from the object types. This is why when it's not known (like on It will be much easier to try help you with this issue if you give me some real world use-case. Currently it's very hard to understand what are you trying to achieve here. |
Sure 👍 In some cases, I want to validate that that input/dropdown value has a minimum length of 1 (so it isn't the "non-selected" case) and in other cases, I want it to be optional and also transform the empty string to So, one use would be export function emptyToUndefined(s: string | undefined | null) {
return !s ? undefined : s;
} I had interpreted PS: I also want this Schema to accept both |
Looks like you need to use const Validator = Schema.either(
string.min(1),
Schema({ key: string }),
); You can add more logic and constraints for each type individually. |
My idea was to convert both parts of that const Validator = Schema.either(
string.min(1).all().the().other().validations(),
Schema({ key: string.min(1).all().the().other().validations() }),
); but instead can do const Validator = stringOrObjectWithKey.min(1).all().the().other().validations() But starting with an export const stringOrObjectWithKey = Schema.either(string, Schema({ key: string })).transform(
(input) => (typeof input === 'string' ? input : input.key),
StringValidator as ValidatorConstructor<StringValidator<[string | { key: string }]>>
); It would be cool if you could add some documentation to the second argument of My first instinct of "construct a string from these two types and continue working on that as if it were a string" seems to have been very much off the mark ^^ |
If on the end you want a string then it make sense to use TypeScript making it very hard to mange that. This library always feels as we pushing TypeScript to it limits. Maybe on the new 4.1 version it will be much easier to address that, but it will also involve breaking change for older versions. I will take a deeper look on this when I have some time. |
Yeah, I know the feeling - I'm a co-maintainer of redux toolkit, and boy, do we have some types.(Including stuff like feature-detecting the TypeScript version and acting different on that 😅) |
Hey there again, sorry that I keep digging up weird stuff :)
I have created a constructed type with
and I can call that just fine like
now, when I chain that like
I lose the ability to call it with the overload:
Looking at the types, I don't really see what is wrong there - and to be honest, these types are quite complicated to get started with so I'm a bit hesitant to do a PR on this.
I have, though, created a type test for this that you can use to verify this behaviour:
CodeSandBox
I hope that helps to pinpoint it down.
Please don't hesitate to contact me if I can help any further 🙂
The text was updated successfully, but these errors were encountered: