-
Notifications
You must be signed in to change notification settings - Fork 327
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
Issues when using intersection and types with fallback #532
Comments
If you replace MyType.decode(undefined) with MyType.decode({}) Then no error is thrown, as I think this is working as intended, and the issue you're running into here is that the use of Potential solutions: You can use a fallback value in your call to MyType.decode(undefined ?? {}) Or you could implement this fallback as a part of your codec with |
@EricCrosson, I would agree with you if withFallback(t.type({ prop1: t.string }), { prop1: 'a' }).decode(undefined); failed. However, this is not the case as it successfully returns |
I disagree that this is expected behaviour. The |
@mottetm thank you for the bug report, patch released. |
@gcanti Thanks for all the awesome work! 🙂 |
🐛 Bug report
Current Behavior
Expected behavior
As both of the subtypes will return a value when decoding
undefined
, the intersection should also succeed (or fail without exception).MyType.decode(undefined)
to be equal toright({ prop1: 'a', prop2: 1 })
Suggested solution(s)
The mergeAll function used to merge all types in the validation of the interface should be able to handle an undefined input. And skip the
u[k] !== base[k]
check.The text was updated successfully, but these errors were encountered: