Where's Match.And?

core
1

I find myself needing something like Match.And all the time, in which case I write a Match.Where that returns condition1 && condition2. There’s Match.OneOf for or-like functionality (||); Match.And would compliment it (&&).

2

Because if you write to check/match statements back to back, it is basically an and :smile:

Check(input, Match.Pattern1) ; 
Check(input, Match.Pattern2) ;

input must pass both tests here, so implicitly there is an and condition there

1 Like
3

@serkandurusoy, that’s true, but I’m using Match with object literals to define Schemas, so it isn’t procedural. This is what I’d like:

import Schema from './Schema'

let Things = new Mongo.Collection('Things')

new Schema({
  someProperty: Match.OneOf(String, Number) // OR
  sibling: Match.And(condition1, condition2) // AND would be nice!
}).applyTo(Things)

This is what I currently have to do, which isn’t as short:

import Schema from './Schema'

let Things = new Mongo.Collection('Things')

new Schema({
  someProperty: Match.OneOf(String, Number) // OR
  sibling: Match.Where(function(value) {
    check(value, condition1)
    check(value, condition2)
  })
}).applyTo(Things)
4

Hm I see. Yes that’s obviously a better syntax. But also, did you see the
discussions around the meteor guide collections/methods where a possible
future with check’s deprecation was hinted/suggested?

5

No, I didn’t. That would be sad as I really like Match and check! I dropped aldeed:collection2 in favor of writing my own simple Schema class that simply applies the given object composed with Match/check to a collection’s documents on insert/update/etc. I really like the Match/check syntax much better than the syntax in aldeed:collection2.

export default
class Schema {
    constructor(spec) {
        this.spec = spec || {}
    }

    applyTo(collection) {
        collection.before.insert((userId, doc) => {
            _checkDocument(this, doc, collection, 'insert')
        })
        collection.before.update((userId, doc, fieldNames, modifier, options) => {
            _checkDocument(this, doc, collection, 'updat')
        })
        collection.before.upsert(function(userId, doc, fieldNames, modifier, options) {
            // TODO
        })
    }
}

function _checkDocument(self, document, collection, action) {
    try {
        check(document, Object.assign({
            _id: String, // TODO: make a MeteorIDString Match type.
        }, self.spec))
    }
    catch(error) {
        throw new Error(`${error.message} while ${action}ing item ${action == 'insert' ? 'into' : 'in'} '${collection._name}' collection.`)
    }
}
6

Well, I use check extensively as well, I also feed simple schema
definitions into check, but the point is MDG is trying to come up with
nice patterns and one of them involves validations around methods and
simple schema as well as collection2 for mutations. There is a new
error type for validations and the discussion is that it would render
check redundant and less powerful and might call for deprecation in
favor of the new validation error patterns. Nothing set in stone yet.

2 Likes
7

Yep, having some discussions here:

8

@trusktr curious, would you still find value in having this feature? I’m considering submitting a PR for it. Would like to hear your thoughts these days. Here’s the thread I posted: Improving Meteor’s check package. Feedback needed

9

Yeah, never too late to add useful features. Wish there was more of that happening in fact!

1 Like