Async callback for "valueIsAllowed" about meteor-simple-schema HOT 8 CLOSED

That's an interesting idea, @petyunchik. In terms of security, you can be secure as it currently works because you can use a Meteor.isServer block within the valueIsAllowed function to do additional checks on the server. As implemented by the collection2 package, for example, the valueIsAllowed function runs once on the client and then again on the server. So there can be additional server-specific checks.

But I can see where being able to get the results of those server checks on the client before actually submitting/inserting/updating would be useful, plus it could be useful for anyone making use of the SS package for some other purpose.

Do you have ideas about what the API for this would be?

from meteor-simple-schema.

It's possible to pass one extra argument to the "valuIsAllowed", which will be of a function that launches the next phase of SS logic. So, then users will be able to use this function in the callback. Also, most likely the function should recieve an argument, which is an indicator of the error. This can be a simple boolean value. Something like next(false) or just next() if checking is passed.

Maybe it should be a separate option valueIsAllowedAsync (or something like this) to do not break logic of the projects, that already use SS. Or you can check returning value of the "valuesIsAllowed", and if it's returns something - then automatically call next().

from meteor-simple-schema.

valueIsAllowedAsync seems like a good option. The only problem is the validation code is pretty synchronous right now, so it might take some work to rewrite. Also, client validation can potentially happen very often if using the autoform package with keyup option, so there is the question of how the delay would affect that. Possibly it could be done so that async can be skipped when calling validate, so that the autoform package could run it only on the submit event.

from meteor-simple-schema.

This is really important! I just tried to make a user register form and want to validate if the username is unique. Currently that is not possible as far as i can see (and really ugly as I have to use the hooks to call createUsers on the client)

As a suggestion: you could work in a meteorMethod field which would be a string.
Meteor automatically prevents them to be called on top of each other but there still would be the need to implement the asyncCallback.

However in a fiber (eg. autoforms output) Meteor.call can and should be used synchronous as it would then react to changes. (Just think: someone deletes his user and your form automatically says that the name is now valid. Edge case pure ;) )

from meteor-simple-schema.

You can add the following to the username schema to ensure uniqueness on both client and server:

{
  unique: true,
  index: true
}

However, you're correct that there won't be any client-side feedback about the reason for the failure (unless you publish all usernames to every client, which I wouldn't recommend). So yes, it's high on my list to think about the best way to introduce asynchronicity with support for reactive client messages. I can't say how fast this will get done, but I'd consider merging a well-thought-out PR.

from meteor-simple-schema.

Well i can't really do that because i think it's better to call Accounts.createUser on the client side because it will encrypt the password before sending it. The same is for the login process.

In fact the users table of meteor should be much better covered in the documentation... for autoform too. How do I validate the user correctly? I use Accounts.validateNewUser but i don't think this covers it. Can I insert a schema into an existing collection (Meteor.users)? I don't know!

from meteor-simple-schema.

OK, right, I forgot we're talking about Meteor.users collection here.

Attaching a schema to Meteor.users is not yet possible, but I plan to add that ability soon. Meteor-Community-Packages/meteor-collection2#44. When that's done, you should be able to attach a schema with the unique/index options like I mentioned (although I believe the account pkg already sets up a unique mongo index on the server).

For autoform, you can use an autoform with your own client side onSubmit that calls createUser. Then you'll get the auto form generation, the auto validation, and still get everything createUser offers, too.

from meteor-simple-schema.

After looking through the code and considering various implementations of async support, I don't think there's any good, simple way to support it natively. SS validation typically occurs in client event handlers, which are inherently synchronous, so we get into some tricky situations with deciding whether and how to preventDefault on events, plus async leads to some pieces of the API being less logical. Also, as I previously mentioned, validation is sometimes run frequently, like on keyup.

However, I did add the ability to manually add errors. So I think a good solution for async is:

1. Call mySSContext.validate. If valid, then
2. Call your async function, and in the callback check for errors.
3. If errors, then manually add a validation error.
4. Else perform the action.

(While waiting for the async call, ideally show some sort of UI feedback, like a spinner.)

That's a solution for generic SS validation. In the more common case where you're validating as part of a C2 collection operation, then you would do the async call before the insert/update. With an autoform, this can be done by using onSubmit instead of built-in insert/update.

from meteor-simple-schema.