Enabling Async Validation in package mdg:validated-method

Hi all,

I use the mdg:validated-method package. Many of my validate functions need to go async and currently it does not support this. Any chance someone familiar can take a look and fix this (I’m not confident myself - having tried and failed)? Maybe it could be added to the S/S

I’d also be interested in other’s experience in how they have dealt with M3 conversion wrt this package. For example, it forces you to have all method code on server and client which used not to be a problem for me as I embraced isomorphism. But isomorphism is not such a fun thing now with M3, so I am refactoring many methods to be server only. As a result I have created a “skipStub” mixin where necessary that stops the client from running the method and I make heavy use of imports set at the start of the run function (which are now all async).

Since I have over 500 meteor methods, it’s a long process…

1 Like

I’m not at that point but we heavily rely on mdg:validated-method and if noone will care for it then I will update it accordingly

1 Like

That would be mighty fine of you if it’s not too much trouble. Someone else advised me that the validate() method was only supposed to be for syntax checking rather than authorisation-type checking, but since this worked fine in the fibers world, I wasn’t to know really. I was girding myself to start refactoring all my 600 method validations into the run method itself, but will hold off if you feel this can be fixed.

Many thanks

why not use GitHub - jamauro/method: An easy way to create Meteor methods ?

Does it support async validation?

Thank you. It looks good. Permission type checks can be put in a before hook and can be async.

I have a natural aversion to changing packages due to perceived work load, but I think it has to be done. The silver lining in all this is that it is an opportunity to rationalise/standardise code that may have become fragmented or inconsistent as the years have gone by and the system has grown.

Hey ho.

I think people may have different ideas of what “async validation” means so I’ll attempt to clarify a bit by saying jam:method supports async functions but validating arguments (i.e. an argument is the type you expect) happens synchronously. If someone has a good use case for true async validation of arguments, I’d be interested to hear it.

I reached out to the OP via DMs to see what their use case is. However, they’re not using validate for argument checking as intended by mdg:validated-method. They have some business logic in there that should be located elsewhere and that was my recommendation to them.

What is the difference between the following validations?

  • amount must be greater than 100
  • amount must be greater than current maximum

The only difference between the two is that one is fixed while the other one is dynamic and based from existing data in the database

I think the point here is that with mtg:validated-method or with Meteor.call() you could combine business logic checking of arguments with plain argument type checking. Nothing wrong in that, in my view. But with M3 that capability no longer works with mtg:validated-method and this is also expected by jamauro:method. I’ve no beef with that policy in principle, except that I have a whole load more refactoring to do.

But jamauro:method does invite “custom validations” which kinda suggests you can do more than just argument check - but no looking at the database! Mixed messages perhaps?

Incidentally, I have loads of custom() methods in my simpl-schema specifications that also refer to the database synchronously - all that has to now be removed and re-sited as I understand?

Bottom line, I think that if you facilitate anything beyond argument syntax checking in your validator, async is a reasonable expectation to be able to refer to the database.

Personally, I don’t buy into the business logic vs non-business logic reasoning here. At the end of the day, we are validating if the inputs of the user is correct or not. The user has to be informed if he needs to change something.

The good thing about the built-in validate function is that it validates all fields whether a field fails or not. Therefore, if 2 fields fail validation, you can inform the user to change those 2 fields - without doing any special handling in your code.

Once you move that validation somewhere else, you need to worry about collecting the errors into an array, joining those errors with the "simple’ field errors, and checking if an error exists and then throwing those errors.

Or else, you will end up with those annoying form error handling that does it one field at a time which sucks in usability especially with long forms

How do you handle these dynamic validations currently?

That is why the question: does it do async validations?

No, in jam:method you have to do DB-dependent validation in a before hook

I appreciate jam:method as being superior to mdg:validate-method because it has better features and if I’m going to refactor, I may as well switch to the better option

Ok so it sounds like you handle these dynamic validations in the validate function currently and are not embedding them in a SimpleSchema custom() function for example. If that’s the case, then how are you accomplishing this:

A simple pseudo code example would be really helpful. My understanding is the validate function in validated-method doesn’t provide the functionality you’re talking about. It’s provided by SimpleSchema.

Yes, that’s one way to approach it. But I’m not opposed to making improvements to support use cases I hadn’t considered. I just need to understand how people want to use it. Thanks for sharing your code example via DM. Code examples are really the best way for me to understand what people are looking for. :slightly_smiling_face:

We do use custom() function of SimpleSchema

The custom function of Simple schema is my next target in async migration, we use it in many places and it’s still one of the USP of Simple schema

1 Like

@rjdavid, if you achieve asyncing of custom() in simpl-schema and validate() in mtg:validate-methods my probems are over in this department!

@jkuester will surely deliver this for validated method, @dthwaite.

@jam might also decide to support this for both easy schema and jam:method

We are very far from even the starting line on this as we deprioritized the upgrade to 3.0 versus business requirements

jam:method now supports using an async validate function, meaning you could do *Async DB queries inside it if needed. :tada:

Note, the schema property remains a synchronous validation for the supported schemas. I’ll wait to see how SimpleSchema handles an async custom() before evaluating changes here.

I’m still evaluating whether jam:easy-schema will support an async where function, which is similar to SimpleSchema’s custom() but with a more straightforward syntax.


Really glad that you’re paying attention to these package and adapting it to the needs of the developers. Great work :clap: :clap:

1 Like