Changes to autoform / simple-schema to fit a generic "validation error" pattern about guide HOT 10 CLOSED

all the details of what these were?

I don't have any notes about what a generic error format needs to support, but I imagine it's an array of errors per key?

One thing in particular that's important to me is that it has first-class support for i18n and doesn't encourage people to print user strings directly from the error.

from guide.

Oh what I meant here were the detailed changes we wanted in SS and AF.

from guide.

The exact notes I took were:

• Changes to autoform:
  • Have callbacks passed in from a helper rather than with a global hook system
  • Support our designed error format
  • Support exceptions in onSubmit and onChange, so that you can use the throwing validator instead of the schema reactive validator
• Changes to simple-schema:
  • Add the equivalent of check that throws the errors described above or just tests for validity
  • Deprecate check and Match

from guide.

There is a trick I use in collection2 which I wanted to standardize into an error type and this is probably a good place and time to do it.

Here is the related code: https://github.com/aldeed/meteor-collection2/blob/master/collection2.js#L410-L474

For a client-side operation, C2 validates on the client for speed and then again on the server for security. Some errors will only happen on the server, especially custom validation that might run checks against other docs that are not published. Also Mongo might throw unique key errors. In both of these cases I:

1. Throw an Error from the deny function (where schema validation happens)
2. Set error.sanitizedError to a Meteor.Error
3. In that Meteor.Error, set the details to EJSON.stringify(error.invalidKeys).
4. On the client, check to see if it seems to be that kind of error. If so, extract invalid keys with EJSON.parse(error.details).
5. Add server invalid keys to client invalid keys.

In the case where it is a Mongo error, there is some extra parsing involved on the server to try to detect which field had the error and translate that into a "notUnique" SS error. (MongoDB has an open issue to make it easier to determine field name from uniqueness errors.)

But in short, I seamlessly merge the server validation context into the client validation context so that any reactive display of errors on the client (e.g., on an autoform) auto-updates to show server errors.

If this can be standardized, then autoform methods can do the same thing, or really any method. You could do this:

Meteor.call('foo', function (error, result) {
  if (error) mySSValidationContext.addInvalidKeys(error.invalidKeys);
});

Really all that is needed is some way to throw errors with objects attached that are somehow designated safe to send back with the client error.

from guide.

@aldeed your page === our page. #51

from guide.

I'm not sure we are tracking anywhere our thoughts on Collection2 btw. Perhaps this should be a separate issue, but @aldeed what we think would be nicer in an ES6 world, would be if you could use SS in a way that didn't require it to monkey patch collection, but instead subclassed.

So I could do

const Posts = new Collection2('posts', {schema: ...});

Or in a case where I wanted to add "hooks":

const PostsCollection = class extends Collection2({
  insert(doc) {
    super(doc);
    Authors.update(doc.authorId(), {$inc: {postCount: 1}});
  }
})

const Posts = new PostsCollection('posts', {schema: ...});

What do you think about this? Does it make sense for you or feel wrong?

from guide.

I would definitely prefer to not monkey patch, but I also don't like added complexity since the simplicity of the current approach is I think why it caught on. In my ideal world we'd add some hooks in a few choice places to the core mongo Collection and then most of the monkey business would no longer be needed. C2 would only extend the prototype with attachSchema and use that info in the hooks. (Extending the prototype with a new function isn't monkey patching IMO, but maybe there is disagreement there.)

from guide.

@aldeed I guess I'm wondering why

Posts = new Mongo.Collection('posts');
Posts.attachSchema(schema);

is preferable to:

Posts = new Collection2(posts, {schema: schema});

In the first case, we've had to monkey patch Mongo.Collection and thus it's now impossible to use a "pure" Mongo.Collection that doesn't pass through the C2 code. Plus in the second case we are really being explicit about inheritance and so it makes it more natural to start sub-classing a collection2 to add our own behaviours (see my second example).

I'm guess I'm not seeing the added complexity of the inheritance approach but I'm probably missing something.

from guide.

@tmeasday I think the first version of C2 did it that way. Hard to remember now, but I think maybe it was changed because people wanted to attach schemas to collections coming from other packages, especially Meteor.users. Maybe that could be achieved by the ability to wrap an existing Mongo.Collection into a Collection2 instead.

from guide.

Yeah I figured the Meteor.users thing could be it. @stubailo we were going to recommend people not use the users collection directly, but we backed off on that. How do we reconcile this?

from guide.