Skip to content
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

Next version #249

Merged
merged 16 commits into from
Mar 4, 2024
Merged

Next version #249

merged 16 commits into from
Mar 4, 2024

Conversation

Keats
Copy link
Owner

@Keats Keats commented Apr 14, 2023

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

@Keats
Copy link
Owner Author

Keats commented May 13, 2023

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
Copy link
Contributor

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

@Keats
Copy link
Owner Author

Keats commented Jul 6, 2023

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

@pintariching
Copy link
Contributor

Is there anybody working on the derive macro rewrite?

@Keats
Copy link
Owner Author

Keats commented Jul 9, 2023

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
Copy link
Contributor

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

@rakshith-ravi
Copy link
Contributor

rakshith-ravi commented Jul 9, 2023

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
Copy link
Owner Author

Keats commented Jul 9, 2023

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
Copy link
Contributor

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
Copy link
Owner Author

Keats commented Jan 11, 2024

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
Copy link
Contributor

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.

pintariching and others added 13 commits March 4, 2024 10:12
* implemented validation trait for length

* converted identation to spaces

* changed the trait to not require HasLen

* added macro for generating impls

* implemented ValidateLength for some types

* using trait validation instead of the function

* added cfg for indexmap import

* changed trait to require length

* Revert "changed trait to require length"

This reverts commit a77bdc9.

* moved validation logic inside ValidateLength trait

* added trait validation for required

* added email trait validation

* fixed trait validation for email

* added range trait validation

* fixed range trait

* added url trait validation

---------

Co-authored-by: Tilen Pintarič <tilen.pintaric@aviko.si>
#246)

* feat(range): add exclusive minimum and exclusive maximum for `range` validation

* test(range): add tests for `exc_min` and `exc_max` range validation

* docs: add docs for `exc_min` and `exc_max` for `range` validation

* chore: rename `exc_min`, `exc_max` to `exclusive_min`, `exclusive_max`

* chore(validation.rs): get rid of `collide` function
* Fully remove code for old phone validation

The phone validation code was partially removed in 897811a (Remove phone
feature and code, 2023-05-12), but parts were left in leading to tests
not passing.

* Update compile-fail expected compiler errors
This test was checking that the derive macro assertion about the type
not being one of the known string types was working, but now since we
allow implementations of the email validation for third-party types
there is no way for us to perform this check in the derive macro.

The same assertion is still used for the credit card and non-control
character validators, but those will also soon be switched to be
trait-based.
* Avoid unnecessary case-insensitive regexes

The case-insensitive flag `(?i)` requires regex with the unicode-case
feature enabled which significantly increases the binary size and makes
regex slower.

* Disable unnecessary/unused regex features

regex crate with default features enabled is huge, it significantly
increases the binary size and compile time.

Cargo features are additive, so once some feature is enabled anywhere in
the dependency graph, there's no way to disable it, i.e. one
(transitive) dependency infects the whole dependency graph.

Since `#[validate(regex = "...")]` takes a path to a static Regex
instance, not regex as a string, users have to add the `regex`
dependency to their Cargo.toml to use it. Therefore, this change
shouldn't break backward compatibility.
* Rewrite derive macro implementation

* Add better error handling

* Add new types to validator macro

* Add empty files in tokens module

* Removed i32 tests for length

* Fix email to pass tests

* fix length validation trait to work with u64 only

* Add credit card token generation to macro

* Add url token generation to macro

* Add ValidateIp trait

* Add ip token generation to macro

* Remove unneeded import

* Export ValidateIp trait from main crate

* Add tests for ValidateIp macro

* Add non control character token generation to macro

* Add test for range with enums

* Add range token generation to macro

* Add required token generation to macro

* Fix ValidationErrors merge function

* Move contains trait to contains.rs

* Add ValidateContains trait and fix tests

* Add ValidateContains and DoesNotContain traits to macro

* Add must match token generation to macro

* Add regex token generation

* Add custom validation token generation to macro

* Add custom validation with arguments to macro

* Add custom validation with args with contexts

* Add custom validation recommit

* Fix custom validation to work without lifetimes

* Change custom validation to use closures

* Fix tests for custom validation

* Change custom validation to implement FnOnce and add tests

* Remove code used for experementing

* Remove unneeded code

* Remove unused imports

* Add schema with arguments and fix tests

* Impl ValidateLength trait for Option types

* Fix impls for ValidateRange

* Fix duplicate use statements

* Fix tests and add Option impls for Contains

* Implement ValidateUrl traits for specific types

* Implement ValidateEmail traits for specific types

* Fix some tests and warnings

* Add regex trait for validation

* Fix to pass tests in validator lib

* Fix range validation trait to pass tests

* Update and remove unneeded dependencies

* Add ValidateNested trait

* Fix custom and nested validation

* Fix Regex validator to work with OnceCell and OnceLock

* Fix derive macro to support all the arguments

* Remove unneeded functions and fix tests

* Remove validator_types crate and fix tests

* Update CI workflow

* Fix custom to be used in nested validations

* Fix custom validation to use context

* Add custom nested validation with args test

* Fix validation to use Validation trait

* Remove conflicting trait

* Fixed tests and remove ValidateContext trait

* Fix nested validation

* Fix custom args test

* Add `nest_all_fields` attribute

* Add better error handling and start fixing UI tests

* Pass almost all tests

* Add skip_on_field_errors attribute to schema

* Remove rust beta channel from workflow

* Use proc_macro_error instead of darling diagnostics feature

* Conditionally run UI tests

* Fix ci.yml

* Fix ci.yml

* Remove UI test for wrong type on range

* Change trait impls to be consistent

* Run cargo clippy --fix

* Replace if else with match

* Remove cargo-expand leftovers

* Replace underscore with `#[allow(unused)]`

* Add support for multiple schema validations

* Remove serde original field name test
* Reduce boilerplate code using generics and macros

* Remove `HasLen`

Plus a couple of clippy suggestions
LazyLock in std is not stable
@Keats Keats changed the title [WIP] Next version Next version Mar 4, 2024
@Keats Keats merged commit 95edf4a into master Mar 4, 2024
8 checks passed
@Keats Keats deleted the next branch March 4, 2024 09:31
@Keats Keats restored the next branch March 4, 2024 09:31
@Keats
Copy link
Owner Author

Keats commented Mar 4, 2024

Ok it's live!

Thanks everyone

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

9 participants