You can easily write a ValidatedMethod mixin! https://github.com/meteor/validated-method#mixins
Exploring.
I like the idea of mixins, but don’t like that they have to be stated in every Method definition. I feel like I’m replacing something that has to be remembered with something else that has to be remembered. The whole point of ValidatedMethod is to hide boilerplate.
I guess I could wrap ValidatedMethod and specify the mixin in the wrapper, but it feels wrong to add another layer of wrapping.
It seems like the ValidatedMethod package should have a method, perhaps “defaultOptions”, that could specify default options including default mixins. Perhaps there was a conversation on this at some point that I could look back at to understand the choice?
1 Like
Not in every call - in every definition. That’s a very important distinction!
I think the easiest thing to do would be to make your own wrapper for ValidatedMethod, like MyAppMethod that just passes the mixins you always use.
Properly chastised and changed 
Somewhat related since I’m essentially writing a SimpleSchema mixin, just what is being imagined beyond the schemaMixin example given in the guide when the guide says
It could be nice to have a SimpleSchema mixin which just lets you specify a schema option rather than having to pass a validator function into the validate option.
Just package infrastructure and some type checking maybe? Perhaps the ability to specify an array of SimpleSchema objects that get automatically combined into one validator function as I did once in my example above? Maybe a check that “validate” wasn’t also specified? (unless arrays of validate functions are supported…)
Maybe the code sample is all there is - but I didn’t want to sign up for maintaining another package!
One thing that keeps coming up in forums and chat rooms is Meteor methods where they want to return the result of a callback.
Nothing is mentioned here, Also, I’m not sure where its explicitly said that you can return a Promise from a Meteor method. Which is what I use.
1 Like
Which promise package are you using?
just the built in one in ES6
from a freshly created project… in the server main.js
then in the client console…
then in the client console…
4 Likes
The React Todos example app imports both method files (/lists/methods.js & /todos/methods.js) on start up. They are imported on the server by /server/register-api.js. Is it necessary to import method files on start up?
It seems like you would only need to import a specific method from client code that calls it.
You need to import them on the server on startup, otherwise when the client calls it there won’t be any method to call!
Thanks, I’m still trying to wrap my head around the importing and exporting. I thought that importing from the client would also register the server side. Sort of like how calling a method runs it both on the client and server.
I’m looking at the code for validated-method and I was wondering, can it be implemented as an npm module rather than an atmosphere module?
1 Like
Not at the moment because it calls Meteor.methods internally. What would be the benefit of making it an NPM module?
Primarily to help migrate away from having another packaging system unless needed. For example if code is meant to be only run on server or on client without resorting to Meteor.isServer check.
My classification for something that would be candidates to go npm are.
Client only packages much like angular blaze templates directive.
Code that can run on both client and server with no modification or if Meteor.isServer.
Code that only has dependencies to meteor-base since there is no need for package resolution then. So meteor/meteor is still game.
Just my two c.
1 Like
Yeah, so this package has deps on meteor-base. So seems like it doesn’t fit your filter?
It does fit. Because it only has meteor dependencies. I was hoping I can limit it further by saying meteor-node-stubs can provide but I guess that does not work.
1 Like
In addition, making it an npm module will help work with this roadmap entry https://github.com/meteor/meteor/blob/master/Roadmap.md#full-transition-to-npm
Right I’m just saying there are a lot of modules that it would make sense to move first, like DDP itself.
1 Like
I thought Apollo will rework or replace DDP