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…
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.
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.
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.
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
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.
jam:method now supports using an async validate function, meaning you could do *Async DB queries inside it if needed.
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.
