-
Notifications
You must be signed in to change notification settings - Fork 25
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
Feedback #39
Comments
Thanks, I appreciate the feedback :).
I agree that this is inconvenient at best. Especially the #[derive(Validate)]
struct Foo {
#[garde(custom(baz))] // no context provided, called with just `bar`
bar: String,
}
fn baz(v: &str) -> garde::Result {
todo!()
}
#[derive(Validate)]
#[garde(context(MyContext))]
struct Foo2 {
#[garde(custom(baz))] // context provided, called with `bar, ctx`
bar: String,
}
fn baz2(v: &str, ctx: &MyContext) -> garde::Result {
todo!()
} Another option is to change how custom validators work by introducing a That being said, I'm not sure how I would get rid of the
The #[derive(Validate)]
struct Foo {
#[garde(inner(custom(baz)))]
bar: Option<String>,
}
fn baz(v: &str) -> garde::Result {
todo!()
} The |
Great response sir. These both seem like good solutions to me! If the derive macro is able to determine the correct function signature to use, I'm sure that would be the better approach. (I've done no work with Rust macros myself, I'm not familiar with the tools at your disposal.) I'm not sure that I agree that passing an unwrapped |
@jprochazk You could only requiere the pub trait Validate {
type Context;
fn validate(&self) -> Result<(), Report>
where
Self::Context: Default,
{
let ctx = Self::Context::default();
self.validate_with(&ctx)
}
fn validate_with(&self, ctx: &Self::Context) -> Result<(), Report> {
...
}
fn validate_into(
&self,
ctx: &Self::Context,
parent: &mut dyn FnMut() -> Path,
report: &mut Report,
);
} |
Last part of this will be resolved by: I'll keep this one closed as it's easier to track the work with an issue dedicated to it. |
Just a few comments! Just some feedback for your consideration -
The custom fn signature requires the second
context
parameter. While I think this is a powerful feature, it's not really necessary for me in most cases so far. Perhaps there could be two custom validation function types? One with context and one without? I feel like creating numerous functions with an second parameter that I never use isn't very elegant.When I have an
Option
wrapped type, it looks likegarde
is passing the fullOption<T>
to the custom validator function. Whereasvalidator
will only passT
. It would seem thatgarde
is forcing me to validateNone
. I suppose there could be a context where aNone
value is invalid? On the other hand, thevalidator
way seems to be - it will attempt to validate an unwrappedSome
but it won't bother validatingNone
. I personally feel this is better (for me). The garde setup also requires me to have two validators: one forOption<T>
and one forT
.garde
is your crate, and I'm sure you designed it the way you saw best. Just offering some food for thought.Thank you again for the great crate!
The text was updated successfully, but these errors were encountered: