New package: mdg:validated-method - Meteor methods with better scoping, argument checking, and good defaults

announce
39

Wow, I like this analysis. Would love to see such things in another topics.

Great job, @sashko!

3 Likes
40

@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.

1 Like
41

I like it. I hope you end up polishing it up, depreciating the other way and adding this to core. Also add the ValidationError.

42

@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:

  1. Why is the guide still about Blaze/Spacebars and Autoform (which is Blaze-based)
  2. Why do we base our method validation technology on Simple Schema, which practically is useless with React form libraries
  3. 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.

43

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!

45

Thank you Tom for the answer. I’ve replied over at this thread since it is more about what to choose right now.

46

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.

47

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
48

Love the idea of this package, thanks a lot!

49

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:

  1. no good schema feature in core (i.e. poor check package),
  2. bad initial design choice that a stub should not return a value,
  3. 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
50

I personally think it should be added to the Meteor namespace, instead of adding a new global.

51

OK we made some changes based on the feedback, we now have a CHANGELOG.md in the repo.

0.2.0

  • Renamed from mdg:method to mdg:validated-method and Method to ValidatedMethod
  • Removed schema option, the way to use SimpleSchema now is by passing SimpleSchema#validator() into the validate option
  • Added a special meaning to validate: null to 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
52

@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
53

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.

54

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
55

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
56
  • 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.
57

Most or all of these things are mentioned at the bottom of the outline. Have you read it?

58

The content can be seen on GitHub in the PR here: https://github.com/meteor/guide/pull/121/files

59

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!