feat(validators): Add validator for each object in an array

[jpbufe3]

Added a new validator, each, which applies a validation function
provided in the options to each of the objects in the array being
validated.

Closes #1

[jpbufe3]

@ansman If options.validator is not a function, I'm currently allowing that behavior without returning an error. Let me know if you think I should change that and I can create separate error messages for the object not being an array and the validator not being a function.

[michaek]

@ansman This seems like a valuable addition. What do you think?

[ansman]

Hmm, I'd rather see that you specify a constraint for each element

[michaek]

I think that's feasible, and I agree that it makes the constraint syntax less complex.

However, the array case is slightly different from the object case: in an object, we know what the keys are that we want to validate, and we can define constraints for these keys one time (in a schema definition, for example). For an array, we would need to programmatically add constraints to the array of data we receive before performing validation. Like I said, it's feasible, but it's a different pattern, and the each syntax would allow us to follow the schema definition pattern for arrays.

Thanks!

[andrefox333]

Any updates to this PR? We'll we see this feature added soon? We could totally use this feature in our project. Thanks :)

[thinklinux]

Seems good 👍 Any progress or ETA on this?

[danny-andrews]

Ping. This looks awesome!

[dreamalligator]

is this or #184 preferred? would love to have this feature!

[deathweaselx86]

What's going on with this?

[recidive]

Hello folks, any update on this nice feature?

[jpbufe3]

@ansman - are you going to accept this? if so I'll resolve the conflicts

[activebiz]

Any update on this? Cant wait to get this one!

[jpbufe3]

It looks like @ansman is no longer monitoring or maintaining this repository. I'm not sure if he wants to add some maintainers to this project or if someone should fork and continue development from there

[deathweaselx86]

+1 to fork. We actually already forked this for this feature. An official fork would be amazing.

…

On Fri, Jul 6, 2018 at 11:13 AM John Bufe ***@***.***> wrote: It looks like @ansman <https://github.com/ansman> is no longer monitoring or maintaining this repository. I'm not sure if he wants to add some maintainers to this project or if someone should fork and continue development from there — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#124 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AABNWSCHFI6SNe_n9HGafv2g6W5miRIAks5uD4zGgaJpZM4IPl2h> .

[vpillinger]

@ansman If you no longer desire to maintain this project I am willing to take it over. Whether by forking or by via contributing to this repo. There is a surprising lack of pure-javascript validation libraries that can be easily used with React/Angular or other front-end libraries.

@nebulousdog I would argue that this implementation is preferred over #184 because it returns an array with the same number of elements as the original data. This mirrors the way the rest of the library works much better and makes it easier to work with by keeping the same format between the original data and the error messages. Additionally, this PR has unit testing while the other does not.

[dreamalligator]

sounds good @vpillinger 👍

[jpbufe3]

@vpillinger - if you end up forking, let me know and I can fix the merge conflicts and put this PR up against your repo

[guilherme90]

Hello, this PR is very important for the validator. Do we have any news about that? Won't you join the master branch?