Are `Match` and `check` here to stay? Is a new alternative in the works?

[aldeed]

1. In general you can add any properties you want to your SimpleSchemas and provide a custom validator function for it. This can be shared as an add-on package. See https://github.com/aldeed/meteor-simple-schema#custom-validation. It’s possible there might be some customization that can’t easily be done right now. I can look into any necessary API changes.
2. I’m working on SimpleSchema v2, and just last night I added a shorthand syntax where you can do name: String instead of name: {type: String} if you don’t need any additional options.
3. I plan to change Number to accept floats in v2, and there will be an integer: true instead of decimal: true. This is a common point of confusion. But it is not a backward compatible change, so needs to wait for the full v2 rewrite to be done.
4. Although the guide recommends SimpleSchema, I think more generally it recommends a pattern whereby the new ValidationError is used to communicate errors better between client and server. This is a general pattern that any package could adopt, so I hope that some interesting other schema check packages are created. If we standardize around this, then UI packages can standardize around reactive display of validation, etc.
5. Packages can be created to take in any schema syntax and output the one that SimpleSchema expects, so I don’t think that disagreement about the flat object structure or anything like that should play any role in what package you choose. You could write JSONSchema syntax or any other and still use SimpleSchema.

[serkandurusoy]

I would really like the ability to extend simple schema “types” with custom functions.

The “custom” itself is powerful but too verbose.

SimpleSchema.registerType("Element", function(val) {
  return _.isElement(val);
});

BlogArticle = new SimpleSchema({
  title: {type: String},
  body: {type: Element}
})

Would have been great.

[aldeed]

body: {type: Element}

Wouldn’t this example work already without the registerType call? In general, since you can set type to anything and it will do an instanceof check, I feel like this is already supported by making your own classes. But I could be wrong.

[serkandurusoy]

Hm, really? I always had the assumption that basic types and objects were my only options. Does it accept a function? Evaluate the function against the value of the field?

[aldeed]

@serkandurusoy, it does not accept a function in that sense. If the type is a function, it assumes it to be a constructor function, i.e. a custom class that the property must be an instance of

aldeed/meteor-simple-schema

aldeed/meteor-simple-schema/blob/master/simple-schema-validation.js#L74-L93

[serkandurusoy]

Hm, well then in that case it does not quite work for me in such a way that the flexibility that Match.Where provides.

In fact, it would really be cool if “custom” could be incorporated into type and had some means of reusability as I suggested above.

[aldeed]

Yeah, I’m happy to look into that, but it would be useful to have a couple realistic real world use cases in mind to understand what the API needs to entail.

[serkandurusoy]

Hi @aldeed thank you very much for taking the time in evaluating this suggestion.

I created a feature request over at github.

EDIT:
Furthermore, I see that some of the issues revolve around some of the SS properties not accepting functions. I second all of them unless there’s some specific reason for avoiding that. Allowing all SS properties to take in functions would make the complete API as extensible and customizable as it gets.

[sashko]

I disagree - I think one of the benefits of not using functions is that you can do things like generate api docs and forms from the schema. If everything is just a function then the only thing you can do is validate and not actually use the data in an intelligent way. Perhaps functions can be an escape hatch for stuff that isn’t possible in other ways but I don’t think a purely function based schema would be a good idea.

[serkandurusoy]

Would merely “allowing” functions break that? Most of the SS properties actually do already allow functions and there are just a couple of them missing this.

[nick]

@aldeed Any plan on making SimpleSchema EJSON serialisable? I know that might be difficult if we rely on custom validations functions, but at least for using standard validators, it would be a very useful feature.

[aldeed]

@sashko’s point is why I haven’t done functions for some props in the past, but I’ve changed my mind on that because I agree we can allow them for the strange edge cases but warn against using them if you want to generate forms or documentation, or serialize. So full support for functions is already on my v2 list.

@nick, I will add EJSON to my v2 list. but it may end up being a separate add-on package. In theory someone else could create such a package right now.

[Steve]

Yes, I’ve run into that as well. I think it would be best if collection2 “cleaning” didn’t silently drop fields that aren’t part of the schema, and threw an error instead.

What makes things even worse, it also cleans the objects you pass into the validation process. So it can happen that your surrounding code runs into issues because fields got lost. This was not obvious to me, and I ran into this trap once. Quite hard to track this down.

Should cleaning be part of a schema package at all?

[sashko]

It’s not - it’s part of collection2.

[Steve]

The SimpleSchema doc is full of references to the “clean” feature. I believe this is puzzling, especially to beginners. If SimpleSchema is to become somewhat standard, I think this should be fixed.

Notice that the check package doc is 3 pages long, whereas SimpleSchema’s doc is 23…

[trusktr]

@aldeed, I think it’d be great if V2 throws errors instead of cleaning, for sure. Basically, it’d be great if all the behaviors of SimpleSchema are completely obvious (f.e. Number -> Float, no cleaning unless explicitly requested, etc). The best default would be to assume that a document should match a Schema exactly as defined, throwing errors otherwise unless options are specified to modify the behavior. :]

[aldeed]

Cleaning code is in SimpleSchema pkg, but no cleaning happens by default when validating. The “cleaning by default” is what Collection2 does. Also, “cleaning” refers to 5 or 6 different things that happen. In general, I think most people actually DO want most cleaning by default since it leads to a better user experience; error messages that can be avoided are automatically avoided. When I hear requests to turn off the “filter” cleaning by default, it is usually due to frustration during development, or not understanding what is happening, not necessarily because it is a bad idea in production.

I think probably the way to please the most people is to keep all types of cleaning on by default EXCEPT filtering out fields that aren’t in the schema. I may also move cleaning to its own package, but it would still be a dep of C2.

[trusktr]

since it leads to a better user experience; error messages that can be avoided are automatically avoided

If an app is tested before being shipped then the UI will theoretically not send invalid data. I think the purpose of the error messages would be for catching developer errors during development.

[raycone]

SimpleSchema might be suitable for some part of meteor developers but check and Match are more universal functions. SimpleSchema is not a real 1 for 1 alternative for check and Match and they should be preserved.

[sashko]

Can you explain which parts of check/Match aren’t easily replaced by SimpleSchema?