-
Notifications
You must be signed in to change notification settings - Fork 140
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
Help with maintenance #201
Comments
I might be able to help you. I already maintain 4 crates. |
That would be great! The main thing to do really is to look at the PRs to see what's missing from them/whether we should close them or not. |
I'm not sure #140 makes sense to have in the library itself |
Domain validation sounds useful, so it might be a good idea to have it alongside the email one. |
I think your PR direction is fine, it only allows for more validation since you would get a compile-time error otherwise. I'm not sure what @krojew means by accidentally ignoring fields for validation. |
I might have misunderstood how that PR works. |
What's the plan on moving forward? |
To amend my question - if you don't want to support the crate, I can take over, since I'm very much interested in keeping it alive. |
#189 is already merged! |
I am seeing staled issue. Should we instore a closing issue policy ? |
I'm not a big fan of stale issues - some old issues are still valid. We should rather go through the issues one by one and close if needed. |
Also happy to help out! |
#205 looks quite good - it will greatly improve extensibility and ease maintenance. |
It would need someone willing to implement it though, it would be a pretty big PR. |
#170 - We don't have the macro logic to support standard Ref and Cell. Any thoughts about this feature? |
I think it's an another argument for implementing #205 |
Agree. We should be able to be backward compatible for at least all Should we focus on #205? |
In my opinion, #205 looks promising and should be prioritized. |
I think with #205 , it might be worth doing a full rewrite of this crate. Probably easier than trying to fit it in and I'm sure the crappy code that was me learning proc macro can be written much better. |
I started to think about #205 as a refactoring without breaking end-user macro-API.
However, I don't have too much time these days. |
I'm not expecting the end-user api to change but all the internals. The issue with a conservative approach is that #192 needs deep refactoring either way, so it's easier/faster to start from scratch imo than bolting on more features |
I noticed this issue and decided to mention my PR here to get potential feedback from active crate users . I'm interested whether the feature is useful enough to integrate into the validator crate. |
What do you think about I think it may be useful to match length constraints in backend and frontend validators - JavaScript returns length in UTF16 characters while |
Seeing as the general consensus is that a rewrite makes sense, and that large breaking changes are unavoidable, I figured I'd try to start from scratch with a new API. I gave it a shot over the weekend, and the result of this is garde. I gathered various feature requests that I found here and either implemented them or created an issue for them. It's mostly the same in terms of usage. The core is a Documentation is a little bare at the moment, so tests are the best place to look for usage examples. The major differences are:
Lots of remaining work to do, but as far as I can tell, the only features which are missing for feature parity with |
There are some neat ideas that I should definitely take for validator.
Sometimes error messages are not generated on the server and you might accidentally log things if there is a default error message (I'm not sure I haven't looked into that in The name |
#[derive(Validate)]
struct Test {
#[garde(range(min=100))]
field: u64,
}
println!("{:?}", Test { field: 0 }.validate(&()).unwrap_err().flatten());
// prints:
// [("value.field","lower than 100")]
It seemed appropriate to me, because I typically use validation in a "guard branch", like: if let Err(e) = thing.validate() {
return Err(e);
}
// or just
thing.validate()?;
happy_path(); But I don't know any French, so fair enough! |
Yeah that's definitely one way to do it and is probably the best way to handle it tbh. |
I am a native french speaker, Example from https://www.wordreference.com/fren/garde
@jprochazk, I think we should have some community chat to work together. |
Hey everyone,
As you might have noticed I'm not very reactive with issues in that repository. The main reason is that I'm not (actually never have) used this crate myself so it's not really a priority for me.
I would be happy to promote some new maintainers to handle the new features/fixes they need rather than being the bottleneck. I will still be available if needed, especially for releases etc of course.
The text was updated successfully, but these errors were encountered: