Open drone1 opened 5 months ago
@drone1 generally I'd say — Use stubs only for user-interaction actions.
What expected behavior you assuming when waitOn
receives stub then server response, page/route reload?
Hey @dr-dimitru!
Maybe it would be helpful to throw an exception before Meteor.setTimeout() if in simulation? I'm not sure if this is an easy one-liner, since the code is running outside of a method, you may not be able to check isSimulation
as you can within a Meteor method. Maybe not worth it.
The behavior I'd expect is to not get an exception thrown by Meteor.setTimeout() being called, and the code moving along as expected as data comes back from the server.
The Meteor docs recommend client stubs for all methods IIRC so I'd gotten into the habit of doing that.
Thanks for getting back.
@drone1 Do you want to push a PR?
I'm having an issue:
flow-router-extra
you're experiencing this issue: 3.9.0 and 3.10.1Meteor
you're experiencing this issue: 2.15This does not work for me:
methods.js (imported on both client and server):
routes.js, imported on the client:
Exception thrown, since you are calling Meteor.setTimeout here:
If I change the Meteor method to have no client stub, the exception goes away:
(...routes.js same as above...)
methods.js
Definiing waitOn() as follows instead does NOT seem to cause the exception:
Originally I was definiing waitOn() with
return new Promise(async (resolve, reject) => ...
and calling a ValidatedMethod, which always defines a client stub as far as I can tell, likeawait myValidatedMethod.callAsync()
, which caused this exception.Would be great if you could support client stubs, but anyway, any suggestions here? Am I doing something unreasonable? Thanks.