Next version

[Keats]

This contains the work needed to make the lib use validation based on traits.

[Keats]

Things that need to be done:

• Use tuples for validator arguments -> we won't need to hardcode an enum of validators anymore I think?
• Put custom function arguments as a param of the struct validation rather than on the rule and have only validate and not validate_args
• remove validator_types crate, I don't think we need it
• rewrite derive macro, it's messy
• handle serde rename properly in the macro: both renameAll and at the field level or remove it entirely

Things that would be very nice:

• Ability to generate openapi schemas (would need to add a few elements like description etc) based on types + validations, although i don't know if it makes sense because we only take care of the input parameters and not the output which is not super useful. Maybe just offer a method to get a list of validations per field?

[rakshith-ravi]

Why is moving to traits better than just calling plain functions, if I may ask?

[Keats]

It's more flexible, any type can implement them - they don't have to live in the validator crate.

[pintariching]

Is there anybody working on the derive macro rewrite?

[Keats]

I don't think so - I was planning to work on it once I'm a bit further with Tera v2 but I would be happy if someone wants to tackle it!

[pintariching]

I can try it this week, I'll open a PR

[rakshith-ravi]

It's more flexible, any type can implement them - they don't have to live in the validator crate.

How would that work for the macro though? As in, would it be a custom validator?

Also, I'm planning to write a crate that does not only validation, but also mutation. For example - if a mutator called lowercase is applied on a String type, it will automatically convert it into a lowercase string, and so on.

Would the next version of validator support mutation? If so, I can directly use this (would be happy to help writing it as well) instead of writing something separately.

[Keats]

How would that work for the macro though? As in, would it be a custom validator?

Not for the validators, for the data structures. You will be able to take whatever map/array/string type you want and implement the traits yourself rather than having them in the validator crate.

Would the next version of validator support mutation?

No, imo that's unrelated business. You could use a custom serde serializer/deserializer fn for that

[rakshith-ravi]

Got it. Thanks for considering it. I'll try writing something over this week and see if I can make a crate out of it. I'll report back with any learnings I would have in case it helps with your next version.

[Keats]

Ok, maybe we do want to ship that PR now and do the other changes (eg error schema changes) in another version? No need to hold it out longer I think.

Thoughts?

[Fishrock123]

I feel like this would be a good change in it's own right, if the change would linger waiting for additional, more complex changes, it might be best to just do separate versions for each of these significant changes.

[Keats]

Ok it's live!

Thanks everyone