You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm writing a package that exposes a few Meteor.methods. Is there a smarter way to namespace them to the package than hardcoding their names like this?
Meteor.methods({'my:package/methodName': function ...
})
This could be made as a wrapper package, which would internally use Meteor.methods, but otherwise expose richer API. I was thinking of making a package for this, where you would do something like:
The idea is that it handles both namespacing, argument checking, and documentation. So argsSpecification would automatically check all arguments, but also make sure that automatically generated documentation for the method would have nice table of arguments with descriptions. So documentation would then be:
package of the method
name of the method
block of documentation
for each argument, name of it, and type, and documentation
We could even document if it is blocking or not (does it call .unblock), but I am not sure how to do this automatically.
A similar wrapper I made for publish functions already: https://github.com/peerlibrary/meteor-middleware (There is additional feature of being able to stack them.) (Documentation feature is not yet implemented.)
SO question, zero replies after one week.
I'm writing a package that exposes a few Meteor.methods. Is there a smarter way to namespace them to the package than hardcoding their names like this?
A way to figure out the name of a package from inside its JavaScript files would be a good start.
The text was updated successfully, but these errors were encountered: