Validation should depend on type of operation

[jpoehnelt]

Currently collection.on('validate', (item) => {}) performs a get and merge before passing the item to the validate callback. It would be beneficial to be able to validate the update prior to the merge. I have different schemas for create, read, update, for example the case of a updated_at column in a db. I want to validate before pushing to the remote server where it will fail.

1. Change callback signature to include the type: 'insert' | 'update' | 'replace' and the raw item which could be in the second arg of the callback { raw: modify({}, modifier) or item.

   (item, 
    {
       type: 'insert' | 'update' | 'replace', 
       raw: type === 'update' ? modify({}, modifier) : item
    }) => void

2. Use another earlier event.

[maxnowack]

Yeah, the validation event was just a starting point to have at least some basic coverage.

To make it more complete, I usually also include a remove event type. However, to stay consistent, that would require the item to be undefined – which isn't ideal.

Another idea could be to introduce dedicated events for each action type (like validate.insert, validate.update, etc.), each with a signature that includes both the previous and the next item. That way, having the item be undefined for validate.remove would make sense.

What do you think?