I like it. I hope you end up polishing it up, depreciating the other way and adding this to core. Also add the ValidationError.
New package: mdg:validated-method - Meteor methods with better scoping, argument checking, and good defaults
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.
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.
That’s a fair question.
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!
Is React really "foolproof" for Meteor right now?
Component suggestions for forms-and-tables-heavy line-of-business app
Next steps on Blaze and the view layer
Thank you Tom for the answer. I’ve replied over at this thread since it is more about what to choose right now.
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.
Love the idea of this package, thanks a lot!
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
- 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?
I personally think it should be added to the Meteor namespace, instead of adding a new global.
OK we made some changes based on the feedback, we now have a CHANGELOG.md in the repo.
- Renamed from
schemaoption, the way to use SimpleSchema now is by passing
- Added a special meaning to
validate: nullto allow people to intentionally skip validation if they need to, for example when a method has no arguments
We’ve also updated the Todos example app: https://github.com/meteor/todos/commit/6a2beedc04f8f2009b19663b477479e4d192202f
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!
Hi guys! Me again.
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.
- Client and server execution differences.
- When to use isSimulation vs isClient (I honestly have no idea!)
- What (if any) interaction with deny/allow rules.
- Isomorphic ID generation options and guarantees.
Most or all of these things are mentioned at the bottom of the outline. Have you read it?
The content can be seen on GitHub in the PR here: https://github.com/meteor/guide/pull/121/files
Not sure what happened there. When I followed the link the first time, the outline.md changes were not there (or I simply did not see them). Browser or brain failure. Sorry to waste your time!
Random idea: what if this package was published under the
meteorguide:methods organization? That speaks more to its context etc
There’s been no mention of this here so far… In an isomorphic app using flux, you would want a store managing incoming actions, so they validate, mutate, etc. In the past I’ve had a meteor method invoke an action on a store after validating it, but given this new package (great job btw on 0.2.0 really appreciate the acute response to our feedback!) I think it might be a good idea to discuss any recommended patterns. Possibly even a little—supplementary—wrapper package/function/whatnot to cut down on boilerplate?
The guide mentions react a few times, and flux not at all. While those two technologies are independent of meteor, a huge chunk of the community uses them with meteor. Especially considering the new Blaze thing (not much interested in blaze, sorry lol) is supposedly going to be sitting atop react.
I’ve been using Alt—this isn’t specific to alt, but flux/redux/etc in general—If we can come up with a recommended Flux+Methods pattern, I’d be more than happy submit a boilerplate abstraction and/or contribute to that section of guide.
Interested in your thoughts on this.
Hmm, this is interesting. I could see the delineation between core packages on
meteor:* and more-or-less optional packages under something separate being beneficial, but then again possibly bad due to less exposure/SEO. This could help cleanup the
./packages directory from the main meteor repo… I’ve never been a fan of having so many things cluttered in one place. (not that meteor should have a separate repo for each one of those packages lol)
A neat diagram comparing Meteor, Flux, and Relay