-
-
Notifications
You must be signed in to change notification settings - Fork 135
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
Type#fallback to mock previous implementation of Type#default #407
Comments
@pyromaniac could you explain how the behavior of |
It didn't fallback to the default when nil was passed explicitly. In general, we lack value normalization in dry-types I believe. Something that adjust values after coercion. Normalization, for example, can be used to turn empty string to nil as well. This fallback proposal is simply a nerfed normalization. |
I'm thinking about having Types::Integer.wrap do |type, input, &fallback|
type.(input, &fallback) + 1
end Similar to how rack middleware works. I'm not quite sure it solves "all the problems" but it does add some flexibility. WDYT? |
This would be actually perfect. I'll be able to build my own fallback type basing on this. Not sure if I got the interface right though. Why do we need those arguments? Wouldn't simple Types::Integer.wrap do |value|
value + 1
end work? The same way as constructor works now, just happens after coercion. |
The idea is you have full control over when the input gets coerced. I'm against adding |
But then this Wrap type becomes a replacement of a Constructor type, it can do everything and more. Great point though. |
Yeah, in a way. Still, I'll play around with the idea in the free time, soon (as always). |
Have a look at dry-rb/dry-schema#337, it looks like we're close to having nice support for this 🎉 |
@flash-gordon it looks awesome, thank you so much for working on this. I believe, DRY lacks this feature in general after |
It merged into master, at the moment I'm testing it in production (looks good!). Once I'm confident I'll cut a release. There are also a few other issues to fix. |
Hey, thanks for a great gems first of all.
I was migrating from dry-types
0.14.0
and faced with the change ofdefault
behavior. There was even a type transformation proposed for dry-struct but I thought that maybe we can address such core functionality on a lower level.I did the following patch:
As you see it just appends a new constructor. But also makes the type
default
to be properly handled by dry-struct.Also, I need to call
optional
first because the constructor gets simply replaced on Constructor typesExamples
Types::Params::Integer.fallback(0)
gives us the same effect as was achieved withTypes::Params::Integer.default(0)
before.We can think about the details of implementation but I believe this feature can be considered for the next version as it is useful.
The text was updated successfully, but these errors were encountered: