To start out, I want to say that if building/releasing this kind of package is not the best way forward, then we won’t do it. This is definitely a request for feedback rather than a set in stone thing.
So here’s how this package came about:
We needed to write an article for the guide about forms and methods.
We started thinking about the best ways to call methods, in line with the patterns @tmeasday had been using at Percolate.
In the initial exploration of the article, the pattern for defining and calling methods became quite verbose - that is from an earlier exploration of best practices for methods.
Even that verbose pattern didn’t handle returnStubValue, and didn’t let you actually display helpful errors on the client when a method invocation failed to validate.
We figured that recommending 15+ lines of boilerplate for every single method call was a bit much, but anything less was not using the Method system to its full potential. Our analysis was that any serious project would need to build its own wrapper class for methods.
Analysis of this thread
Please let me know if I’ve mis-represented your position.
@avital says “I love the idea of eliminating magic strings, but I don’t want to be forced to use simple-schema”
@waldgeist says “Good idea to make method invocation easier, this has some built in features that are very hard to find otherwise, but we shouldn’t tie it to simple-schema”
@Steve says “meteor-call-sync has been doing this for a while, having returnStubValue and throwStubExceptions on by default is a good idea.”
@jhartma says “This is a big improvement of methods, and I would happily switch over to use the package. However, I wouldn’t want to use it in a real business app without a guarantee of support.”
Against:
@msavin says “The guide should explain the underlying issues and teach people how to make a method wrapper for themselves. We should make sure this package is not presented as a replacement for methods.”
@serkandurusoy says "I really don’t want MDG to start building things around simple-schema, since it’s not a standard and there are some alternatives that might be better. The proposed API seems much better than the previous method API, but I’m uncomfortable for new packages to be introduced in this way.
Neither:
@SkinnyGeek1010 says “I also wrote a wrapper for methods, which looks different and enforces some modularity in a different way. I think the most important part is understanding what methods exist, and making them easily testable.”
@deanius says “A good method API would include support for promises.”
Conclusions
It’s clear from the conversation that the current method API isn’t ideal, and there is some boilerplate involved to write good, maintainable methods. A wrapper package isn’t necessarily the best way to deal with the situation, but if we had to reproduce the boilerplate in every place in the guide where methods are involved, it would be very difficult to read.
Decouple simple-schema: The built-in simple-schema integration set off some alarms for people. aldeed proposed a simpler API that allows any type of schema to be used, as long as you can write a function that throws validation errors. I think going with that is a good idea. While we are definitely going to be writing code samples for the Meteor guide using simple-schema for a lot of stuff, there’s no reason for it to be hardcoded into anything if it doesn’t have to be.
Guarantee of support: If we release this as a package that we intend people to use, it needs to be maintained. Methods are a crucial part of the Meteor app writing experience, and you wouldn’t want to have bugs in that system introduced by some wrapper code.
Another option - DIY method wrappers?
There’s one other option other than introducing a package - teach people to write their own method wrapper that encodes some of the same practices. The main downside here is that encouraging people to write custom wrappers for methods will significantly cut down how easy it is for someone to understand a Meteor app they haven’t worked with before. First you’ll have to read and understand that particular project’s method wrapper code. So there are benefits to a standardized wrapper package.
@sashko although the for/against/neither breakdown is somewhat convoluted in its own regard, I think this is a great breakdown and it fills me with joy to see how well you/mdg can assess a given situtation with all of its complexity. Kudos.
I sincerely believe that all arguments pro/con given for the blaze announcement applies here as well, in fact to everything Meteor and I guess the overall concerns are about the API stability and long term support. For this thread specifically, I wish the proposed method api did take cue from the openness of the view layer such that things like schemas/models could be planned out to be more interchangeable.
Apart from that, I find the direction quite pleasing and in line with the overall feel of Meteor.
@sashko@tmeasday I could not figure out where exactly this question belongs, so bear with me please.
I’m about to take on a new, fairly large line-of-business app which will be heavy on tables and forms especially. So I figure, why not give mdg:method a try and also apply the concepts from the “guide”, if there is anything I had not been doing, you know except for React.
I’m kind of surprised to see that the guide uses Blaze. While - even before @gschmidt’s similar announcement - you’ve expressed your current, forward-looking recommendation as React being the safest way to go, the guide mentions React only as an alternative view layer.
I’ve especially gone through the outline issue that deals with methods (that explain the background to this forum thread) and forms. Both validation and form generation are tied to Simple Schema. (And that’s exactly the set up I’ve been used to actually)
Then I took a couple of hours to look around for React form component libraries and as expected, none of them work with SS. It seems JSON Schema kind of has its presence felt in there.
Now, this brings me back to this thread with the following questions; if Blaze is going to be obsolete and React is the way to go:
Why is the guide still about Blaze/Spacebars and Autoform (which is Blaze-based)
Why do we base our method validation technology on Simple Schema, which practically is useless with React form libraries
And what would you have a (fairly experienced meteor dev) do, if they were about to start a forms-heavy project
Seriously, though, I need some guidence, and (parts of) the “guide” seems to be already obsolete although you are taking serious steps (like the mdg:method package) towards the guide’s direction.
Edit:
I’ve also posted Component suggestions for forms-and-tables-heavy line-of-business app as a general call for help on this matter. So if you believe this post pollutes this thread and still would like to share your opinions, you are welcome to do that there, provided that, you also share your opinions regarding the overall “direction” that we’re going with meteor/guide etc. Thanks.
A lot of the details are still being hashed out (and we are taking into account what people have been saying in the other threads), but I’m at this stage I’m pretty confident that we’ll see a solid transition plan from a world where we recommend Blaze to a world where we recommend a Templating layer built on React.
Although starting a project in pure React seems like a pretty foolproof way to avoid any transition issues (and that’s what @sashko’s said), I think there are plenty of reasons why you might not want to do that (either due to the issues that the Templates+React project aims to solve, or simply that you want to use all the existing Blaze goodness that’s out there).
Anyway, given the eventual transition plan, I don’t think you should be overly concerned about starting a Blaze project right now. For the same reason, we still think we’ll be focusing on Blaze in the guide, as one of the aims of the guide is to document how to write apps right now rather than at some theoretical point in the future.
I know the lack of complete clarity right now is frustrating, and I’m hopeful that some things will be clarified further very soon!
Not sure I agree with “clearer errors shouldn’t matter” – your security shouldn’t rely to any extent on obscure error messages. So - not sure why you suggest clear errors could be a liability.
Yes, the form example is a good one. So how would that work? Is there a way on the client to capture the method validation errors so that they could be displayed? Or is that a different pattern?
@sashko yeah I’d like to hear your opinion on this as well. Currently, that’s one of the more painful parts of forms handling in Meteor. Do you have a pattern in mind? Autoform has its own patterns, but there are also other patterns one can take cue from, such as templates:forms, useful:forms, quietcreep:formation and quietcreep:fabforms which in fact builds on json-schema. There’s also the astronomy example with forms which also has some quite nice patterns.
Although I can see what this package can bring to a project - as a design pattern -, I am a bit uncomfortable with the current process and with the fact that it is lead by MDG/@sashko.
Meteor has the following problems:
no good schema feature in core (i.e. poor check package),
bad initial design choice that a stub should not return a value,
bad initial design choice that an exception in the stub should not prevent the RPC.
To me, those are the actual reasons why mdg:method might be useful.
But I think fixing the Meteor problems would be better than proposing a semi-official package.
@sashko, why don’t you just fix 2 and 3 today? Why don’t you announce that you want an improved version of simple-schema to replace check in the next Meteor release and that you want the community to work on it?
We think this will be much better because now the package is not coupled to SimpleSchema, so anyone can write a validation function using whatever schema they like.
@sashko I think the changes reflect the feedback really well, And I like how you summed up the feedback und responded to it, really good to see things like this happening!
Anything you’ve always wanted to know about methods but were afraid to ask?
We’ve decided to decouple forms and methods in the Meteor guide, so I’ve just written up guide article outline for Methods. Please comment on the PR below:
Let me know if there are some mysteries about how methods operate that I need to unravel.
Also, speaking of forms, what is the community going to do in the way of a forms package now that we are on the React track? The leading form package, Autoform, it seems will not migrate over and AFAICT nothing to replace it on the horizon.
This is one of the biggest obstacles to fully migrating over to React for many IMO.
What is your advice/thoughts on this topic (or should I start another thread on this)?
That’s probably for another thread. The short version is, it might make sense to keep building your app in Blaze if you want to use the ecosystem of forms stuff, user accounts UI, etc. For some people that’s not as important, so those people can easily migrate right now. We’ll need to work with some of the authors of those popular packages to see what the best way is to create an analogue that works with React.