I have a short piece of code, like so, to update the name in my user's profile:
Meteor.users.update({_id: Meteor.userId()}, {$set:{"profile.name": name}});
When I'm working locally, I can use Meteor.userId or Meteor.userId() without issue. However, when I deploy to Modulus, I run into issues. If I don't have the operator on it, it will do the initial $set, but no more. If I user the operators, it behaves as I would expect.
Why is this? I assume that I shouldn't have been using this without the operator to begin with, but is there a reason why it worked at all?
Have a look in the documentation
The function Meteor.userId() is available "Anywhere but publish functions"
The variable this.userId is available "Anywhere" (which explicitly is also called out for the Server side Publish function).
I have had the same issue with Meteor.userId() when trying to get a unit testing with mocha to work.
A simple fix is to go to tasks.js and replace Meteor.userId() with this.userId which
is to use the this context of the function.
Related
Every time I refresh the page I receive the following console warning for every single helper that is returning something to template from collection. I know the reason is because the subscription is not ready yet, but what is the solution?
Exception in template helper: TypeError: Cannot read property 'x' of undefined.
I'm already using if(collection.find({}) !== undefined) , but this makes my codes so messy, there must be a way to fix this issue. then I tried guards and still not 100% solved.
In addition to Brendan's answer, using Blaze you can check if the subscriptions for the template is ready using
this.subscriptionsReady()
Which checks all the subscriptions scoped to the template with
this.subscribe()
in your onCreated or onRendered blocks
Meteor.subscribe returns a handle with a reactive method called .ready(). You can use that in your helper to only return the mongo cursor once it's ready.
Edit: docs
I'm trying to follow the "Use the return value of a Meteor method in a template helper" pattern outlined here, except with collections.
Essentially, I've got something like this going:
(server side)
Meteor.methods({
queryTest: function(selector) {
console.log("In server meteor method...");
return MyCollection.find(selector);
}
});
(client side)
Meteor.call('queryTest', {}, function(error, results) {
console.log("in queryTest client callback...");
queryResult = [];
results.forEach(function(result) {
// massage it into something more useful for display
// and append it to queryResult...
});
Session.set("query-result", queryResult);
});
Template.query_test_template.helpers({
query_test_result: function() {
return Session.get("query-result");
}
});
The problem is, my callback (from Meteor.call) doesn't even get invoked.
If I replace the Method with just 'return "foo"' then the callback does get called. Also, if I add a ".fetch()" to the find, it also displays fine (but is no longer reactive, which breaks everything else).
What gives? Why is the callback not being invoked? I feel like I'm really close and just need the right incantation...
If it at all matters: I was doing all the queries on the client side just fine, but want to experiment with the likes of _ensureIndex and do full text searches, which from what I can tell, are basically only available through server-side method calls (and not in mini-mongo on the client).
EDIT
Ok, so I migrated things publish/subscribe, and overall they're working, but when I try to make it so a session value is the selector, it's not working right. Might be a matter of where I put the "subscribe".
So, I have a publish that takes a parameter "selector" (the intent is to pass in mongo selectors).
On the client, I have subscribe like:
Meteor.subscribe('my-collection-query', Session.get("my-collection-query-filter"));
But it has spotty behaviour. On one article, it recommended putting these on Templates.body.onCreate. That works, but doesn't result in something reactive (i.e. when I change that session value on the console, it doesn't change the displayed value).
So, if I follow the advice on another article, it puts the subscribe right in the relevant helper function of the template that calls on that collection. That works great, but if I have MULTIPLE templates calling into that collection, I have to add the subscribe to every single one of them for it to work.
Neither of these seems like the right thing. I think of "subscribing" as "laying down the pipes and just leaving them there to work", but that may be wrong.
I'll keep reading into the docs. Maybe somewhere, the scope of a subscription is properly explained.
You need to publish your data and subscribe to it in your client.
If you did not remove "autopublish" yet, all what you have will automatically be published. So when you query a collection on client (in a helper method for example), you would get results. This package is useful just for quick development and prototyping, but in a real application it should be removed. You should publish your data according to your app's needs and use cases. (Not all users have to see all data in all use cases)
What is the difference between Meteor.autorun and Tracker.autorun?
are they just aliases?
is one deprecated?
is there any instance where one is preferable to the other?
I'm well aware of the difference in using this.autorun in template lifecycle callbacks, but have seen these two used interchangeably and just want to be sure I haven't missed a trick.
Well, it can easily be found out with the identity operator.
This will be false because it is not the same function:
(function() {} === function() {})
Let's try with the two autorun :
(Meteor.autorun === Tracker.autorun)
This returns true. So yes it's only a pure alias.
However, only Tracker.autorun is documented. I suspect some kind of old API left for compatibility...
Let's check some Meteor code on GitHub!
File : deprecated.js
Meteor.autorun = Tracker.autorun;
This is in deprecated.js, it says some things about //Deprecated functions and some backward compatibility with Meteor 0.5.4. It seems pretty clear which one you should use.
You can find some other old timers in there, such as Deps...
Try to run Meteor.autorun(); in the console, it throws the following error Uncaught Error: Tracker.autorun requires a function argument like you were trying to run Tracker.autorun();
my app was using deaunius:promise package for promises, now it is deprecated, and I have to translate all my promises to the syntax of okfrow:promise package, I was trying to understand how to create meteor Promises with that package and how to translate my current Promises to the new package but Im not sure how to do it in the proper way, it is quite different for me...
This is one example of a promise I used to write with deanius:promise
Meteor.promise('sendSubmission', null, submission)
.then( (result) ->
FlashMessages.sendSuccess "Successfully Finished the Test"
Router.go 'submissionView', _id: result.submissionId
).catch (error) ->
FlashMessages.sendError error.reason
Router.go 'takeTest', slug: currentTest.slug
How to write the above promise using okgrow:promise package? the examples they provide are not helpful at all for me. Thanks for your help
my app was using deaunius:promise package for promises, now it is deprecated
That wording seems to be unfortunate. Instead of being "deprecated", I'd have said "moved" - nothing really changed but the repository; it's still maintained by the same contributor. The code is just a fork, much of it is probably still the same.
I have to translate all my promises to the syntax of okfrow:promise package
No. The API has not changed a bit. All you would need to do is update the name of your dependency.
Currently it seems not to be possible to force a ready() state in the route. For example:
I have a waitOn on 2 subscribtions. One of them returns a Meteor.Error - now the route will be in the loading-state with no ending.
Is there a recommend way to tell iron-router "waitOn until subscribtion is ready OR subscribtion fails with an error" ?
Edit:
To explain my special case:
The waitOn is for a route which is for searching. The search arguments are "what" and "where". In "where" I have a plan String Address and need to convert it to a geo coordinate. For this I use the googlemaps converter on the Serverside (because its Sync). When no address was found I need to get back a error a lá "This address must be wrong". For this I need the functionality to get back an error.
When I do it like David Weldon said I need to do this step in the waitOn method but the Client-Side googlemaps converter is not Sync - instead its async so this would not work.
General Recommendations
It's okay for your publishers to throw errors, but those conditions should only be hit if the client does the wrong thing. In other words, you are solving the wrong problem - you should only subscribe when you know the publisher will not throw an error. Let's look at an example:
Suppose your route needs to subscribe to newPosts and postsForSuperuser. Assume that the postsForSuperuser publisher will throw an error if the user isn't a superuser. It's now the client's job not to let that happen. The waiton definition could look like:
waitOn: function() {
var subs = [Meteor.subscribe('newPosts')];
if (Roles.userIsInRole(Meteor.user(), ['superuser']))
subs.push(Meteor.subscribe('postsForSuperuser'));
return subs;
}
Because we are conditionally adding the postsForSuperuser subscription, we don't give the publisher the opportunity to throw an error.
Your specific use case
You case is a little more tricky, because mechanically the client is doing the correct thing but the user input may happen to be bad. In this case, I don't think throwing an error is appropriate. Here are some recommendations:
Avoid the problem by checking the address via a method call prior to changing the route.
If an address is found to be invalid, have the publish function immediately return this.ready(). This will prevent your route from failing, but you'll be left assuming that the reason you have no data is because of the address. If that's a valid assumption (i.e. it's the only possible reason for failure), then your router could deal with this by using a dataNotFound hook.
If you need to explicitly identify the cause of the error, have a close look at the 'counts' example from the docs. You can declare a client-only collection called addressErrors and then call this.added with a dynamically created document describing the cause of the error. The implementation of this is a little more tricky, and probably worthy of a separate question if you get stuck. I'd see if the first two make sense before attempting it.