Split the Key rule into different ones #1416
Replies: 2 comments 1 reply
-
Makes a lot of sense. There is some interplay of these ideas in the 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 |
Beta Was this translation helpful? Give feedback.
-
It's all done in the |
Beta Was this translation helpful? Give feedback.
-
The Key rule does two things:
I wonder if having a
KeyPresent
and aKey
rule would make it more clear and reduce the complexity of theKey
rule a little bit. The same for for theAttribute
rule.Beta Was this translation helpful? Give feedback.
All reactions