I like it. I hope you end up polishing it up, depreciating the other way and adding this to core. Also add the ValidationError.
@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.
Hey Serkan,
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!
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.
1 Like
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
checkpackage), - 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?
2 Likes
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.
0.2.0
- Renamed from
mdg:methodtomdg:validated-methodandMethodtoValidatedMethod- Removed
schemaoption, the way to use SimpleSchema now is by passingSimpleSchema#validator()into thevalidateoption- 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.
4 Likes
@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!
1 Like
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.
Thanks @sashko.
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)?
1 Like
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.
1 Like
- 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?
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
###Flux.
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)