Split the Key rule into different ones

[henriquemoody]

The Key rule does two things:

1. Check whether the key exists
2. Check the value of the key against another rule

I wonder if having a KeyPresent and a Key rule would make it more clear and reduce the complexity of the Key rule a little bit. The same for for the Attribute rule.

[alganet]

Makes a lot of sense. There is some interplay of these ideas in the KeySet rule as well (validating the structure vs. validating data within a given structure).

I would say the best way to move forward with this is to sketch up a couple of use cases, and find a good balance between ergonomics and adherence to single-responsability principles.

That said, I also like the idea of rules that create smaller, more granular rules inside.

This feels repetitive:

v::keyPresent('name') ->keyPresent('phone') ->keyPresent('address') ->key('name', v::stringVal()->...) ->key('phone', v::numericVal()->...) ->key('address', v::stringVal()->...) ->key('tiktok', v::stringVal()->...)

This one feels more natural and intuitive for end-users:

v::mandatoryKeys([ 'name' => v::stringVal()->..., 'phone' => v::numericVal()->..., 'address' => v::stringVal()->..., ])->optionalKeys([ 'tiktok' => v::stringVal()->... ])

The second example could be some sort of aggregating rule though. You use it as ->mandatoryKeys but inside, it generates KeyPresent instances. To make that work, we would need some work on rule aggregation though, specially to design an API that makes clear how to deal with the messages.

[henriquemoody]

I like that approach! In that case, would you also have a MandatoryKey and a OptionalKey rule?

[henriquemoody]

It's all done in the main branch! 🐼