According to this article here:
https://dweldon.silvrback.com/common-mistakes
Subscriptions don't block
Many aspects of the framework seem like magic. So much so that it may
cause you to forget how web browsers work. Take this simple example:
Meteor.subscribe('posts');
var post = Posts.findOne();
The idea that post will be undefined is the root cause of roughly one
in twenty meteor questions on stackoverflow.
So then why doesn't subscribe have a callback, and if it does, why isn't it referenced more often by the Meteor literati?
Why don't we have:
Meteor.subscribe('posts', function(err, posts){
//when the items/posts actually arrive
});
I hope my question makes sense.
Maybe I don't get the question, but the Meteor.Subscribe function has callbacks named onError and onReady methods.
Optional. May include onError and onReady callbacks. If a function is
passed instead of an object, it is interpreted as an onReady callback.
From docs.
For example.
Meteor.subscribe("posts", {
onReady: function () { console.log("onReady And the Items actually Arrive", arguments); },
onError: function () { console.log("onError", arguments); }
});
Also check this GitHub issue
Note: I have updated the article after reading this question.
While subscribe does have an optional callback, I intentionally avoided it in the original article because there aren't currently any common patterns that use it. In other words, I didn't want readers to come away from the article thinking that callbacks were actually the right solution to this problem.
In production applications, subscriptions typically come in two flavors:
Global: initiated as soon as the client starts, or maybe in an autorun.
Route: initiated as via a subscriptions or waitOn option.
It's also worth noting that in recent weeks, the template subscription pattern has emerged, though it hasn't seen wide adoption yet.
In all of these cases, the subscription is started and then can either be asynchronously checked for a reactive ready state, or ignored with the use of guards to prevent reference errors.
Because ready is reactive, this effectively gives us the same benefits of a callback, but with fewer lines of code. Let's look at two examples:
example 1
Meteor.subscribe('posts', function() {
Session.set('postsReady', true);
});
Tracker.autorun(function() {
if (Session.get('postsReady'))
showFancyAnimation();
});
example 2
var handle = Meteor.subscribe('posts');
Tracker.autorun(function() {
if (handle.ready())
showFancyAnimation();
});
Both examples demonstrate the same concept - subscribing and then reactively testing the state of the subscription. As you can see there really isn't a benefit to the callback.
Finally, (as I now point out in the article), subscriptions are often spatially separated from the code which uses them. You'll typically subscribe in your route code and consume the results in your templates. For this reason you almost never see code which looks like:
Meteor.subscribe('posts', function() {
showFancyAnimation();
});
In fact, the only place I ever encounter code like the above is in SO answers because the author is trying to make a quick demonstration rather than trying to show a typical usage pattern.
Meteor.subscribe has been enhanced since v1.2. One of its callbacks onError is now replaced with onStop in Meteor v1.2.0.2 documentation
callbacks Function or Object
Optional. May include onStop and onReady callbacks. If there is an
error, it is passed as an argument to onStop. If a function is passed
instead of an object, it is interpreted as an onReady callback.
Having that enhancement, Meteor.subscribe is used with callbacks as an object
Meteor.subscribe( 'collection', {
onStop: function( error /* optional */ ) {
// when the sub terminates for any reason,
// with an error argument if an error triggered the stop
},
onReady: function() {
// when ready
}
});
However, onError still works for backward compatibility. Be aware that some popular packages, such as SubsManager still uses onError. That being said such snippet below is now deprecated but doesn't break .
Meteor.subscribe( 'collection', {
onError: function( error ) {
// if the subscribe terminates with an error
},
onReady: function() {
// when ready
}
});
On the other hand, Meteor.subscribe can be used with a callback as a function as before
Meteor.subscribe( 'collection', function() {
// when ready
});
As my personal notice, if Meteor.subscribe happens to be passed with careless multiple callback functions, only the last one takes effect as the onReady callback.
Meteor.subscribe( 'collection', function() {
// this doesn't execute.
}, function() {
// when ready.
});
The associated Git commitment is listed here for a reference.
Related
How To Subscribe multiple Publications in meteor without waiting for each other and not using unblock package??
You can register one publish function and return array of cursors:
Meteor.publish('yourPublications', function () {
return [yourPublication1Data, yourPublication2Data, yourPublicationData3];
});
And subscribe only once:
Meteor.subscribe('yourPublications');
You can add this.unblock(); in your publication to unblock:
Meteor.publish('yourPublications1', function() {
this.unblock();
return yourPublication1Data;
}
Meteor.publish('yourPublications2', function() {
this.unblock();
return yourPublication2Data;
}
Meteor.publish('yourPublications3', function() {
this.unblock();
return yourPublicationData3;
}
Then you can subscribe these publication on route or template render.
Meteor.subscribe('yourPublications1');
Meteor.subscribe('yourPublications2');
Meteor.subscribe('yourPublications3');
I am afraid you will need the package or code the same thing like the package does, yourself. I just installed lamhieu:unblock and it works great. But I don't fully understand what it is doing - that code is a bit high level for me.
Grunt will output exit codes and that's fantastic for scripts executing grunt tasks but I want the ability to handle failed grunt tasks after grunt completes them.
I was expecting to find some type of error handling function that I could set in the initConfig somewhere but I don't see anything. Likewise, even a "finally" function would work nicely.
Basically, I have an alias task that is a set of tasks that I execute and one of them temporarily changes content of a file and I write the content back to disk after everything completes. I want to still be able to at least attempt to write the content back to disk even if tasks after the mutation occurs, fail.
Something to this affect would be great.
grunt.initConfig({
onError: function (error) {
// execute my file cleanup
},
// this is essentially a "finally" function that executes once grunt
// finishes with all tasks.
onComplete: function () {
// execute my file cleanup
}
});
I am pretty sure, that there is no such feature. But it is a popular request: 1, 2.
What can be done by now? You can write a custom grunt-task, something like the following:
var errorCb = function() { callback(); }
var doneCb = function() { callback(); }
grunt.initConfig({
task_runner: {
before: ...,
beforeEach: ...,
run: ['other_task1', 'other_task2'],
after: ...,
afterEach: ...,
onError: errorCb,
onComplete: doneCb
},
other_tasks: { ... }
});
And register your task:
grunt.registerTask('task_runner', "Tasks' lifecycle", function(task, message) {
// foreach task in tasks: grunt.task.run(task)
...
// except(`grunt.util.error`)
});
As I know, there is no beatiful way to get the result of a task run. So here comes the monkey-patching. It is possible to hook these functions: grunt.fail and grunt.log.error.
Here's some inspiration: 1, 2. Also, have a look at grunt-then.
All in all, I can not say that it is an easy task. I hope someday Grunt will have events (by now: "Note that Grunt doesn't yet emit any events, but can still be useful in your own tasks.").
P.S. Have you considered Gulp for your project?
P.S.S If you are going to write your custom task, feel free to ask me for a contribution.
It's evident how to provide route-specific data, i.e. through the use of a controller:
PostController = RouteController.extend({
layoutTemplate: 'PostLayout',
template: 'Post',
waitOn: function () { return Meteor.subscribe('post', this.params._id); },
data: function () { return Posts.findOne({_id: this.params._id}) },
action: function () {
this.render();
}
});
But how does one provide data for the application in general? In the case that every route needs to be subscribed to the same subset of information, so that the pub/sub doesn't need to be re-done on every route change. Thanks!
It sounds to me like you are looking for a completely general publication/subscription scheme so that you do not have to define the waitOn/data option combination for every single route or route controller that you define. In that case, you can simply publish a given set of data on the server like so:
Meteor.publish('someData', function() {
return SomeDataCollection.find({});
});
and subscribe to that set of data on the client like so:
Meteor.subscribe('someData');
With this publication/subscription pair setup, you will have access to the data provided in all routes. You just have to make sure that you check for non-existent data in your code to handle the first load of any given template when the data has not been loaded on the client yet. In this manner, you would never have to actually define a the waitOn and data options for any route or route controller.
If you would like to utilize Iron Router in a different way than through route controllers, you also have the option of waiting on one/many subscriptions globally by using the Router.configure({}); function. To use the example above:
Router.configure({
waitOn: function() {
return Meteor.subscribe('someData');
}
});
For information about this route option and all of the other options that you have available at a global level, check this out.
In the next phase of my Meteor journey (read: learning the ropes!), I'd like to implement a simple search based on user inputed values, then redirect to a route specific to the record returned from the server.
At the moment, I'm picking up the inputed values via this code:
Template.home.events 'submit form': (event, template) ->
event.preventDefault()
console.log 'form submitted!'
countryFirst = event.target.firstCountrySearch.value
countrySecond = event.target.secondCountrySearch.value
Session.set 'countryPairSearchInputs', [countryFirst, countrySecond]
countryPairSearchInputs = Session.get 'countryPairSearchInputs'
console.log(countryPairSearchInputs)
return Router.go('explore')
Happily, the console log returns the desired countryPairSearchInputs variable - an array of two ids. In my routes.coffee file I then have the following:
#route "explore",
path: "/explore/:_id"
waitOn: ->
Meteor.subscribe 'countryPairsSearch'
On the server side, I have:
Meteor.publish 'countryPairsSearch', getCountryPairsSearch
And finally, I have a search.coffee file in my /lib directory that defines the getCountryPairsSearch function:
#getCountryPairsSearch = ->
CountryPairs.findOne $and: [
{ country_a_id: $in: Session.get('countryPairSearchInputs') }
{ country_b_id: $in: Session.get('countryPairSearchInputs') }
]
With regards to the search function itself, I have a CountryPairs collection where each record has two ids (country_a_id and country_b_id) - the aim here is to allow users to input two countries, with the corresponding CountryPair then being returning.
I'm currently struggling to tie all the pieces together - the console output on searching is currently:
Uncaught Error: Missing required parameters on path "/explore/:_id". The missing params are: ["_id"]. The params object passed in was: undefined.
Any help would be greatly appreciated - as you can probably tell I'm new to Meteor and am still getting used to the pub/sub methodology!
Edited: mixed up client/server for the publish method when I first posted - the danger of late-night posting!
First, seems you're expecting an :id parameter on your 'explore' route.
If I understand you're case, you're not expecting any params here, so you can just delete ':id' from your route:
#route "explore",
path: "/explore/"
waitOn: ->
Meteor.subscribe 'countryPairsSearch'
or either add a params to your Router.go call:
Router.go('explore', {_id: yourIdVar});
Secondly, you're trying to use a client function: Session.get() server-side. Try to update the publication using a parameter ; or using a method.call.
client-side
Meteor.subscribe 'countryPairsSearch' countryA countryB
not sure about the coffeescript syntax, check http://docs.meteor.com/#/full/meteor_subscribe
and server-side
#getCountryPairsSearch = (countryA, countryB) ->
CountryPairs.findOne $and: [
{ country_a_id: $in: countryA }
{ country_b_id: $in: countryB }
]
I want to use a reactive counter var on server side. But I can not guess how to do it without using collections.
I expect {{count}} will be updated after server count var changed without refresh a page or how to send a client that the count was changed?
<body>
{{> test }}
</body>
<template name="test">
{{count}}
</template>
client:
Meteor.call('count', function(err, result) {
console.log(result)
Session.set('count', result)
})
Template.test.helpers({
count: function () {
return Session.get('count')
}
});
server:
var count=0
Meteor.startup(function () {
Meteor.setInterval(function() {
count++
}, 1000)
});
Meteor.methods({
count: function() {
return count
}
})
My code on MeteorPad
I want to see what I expect:
Client:
Meteor.subscribe('count')
Template.test.helpers({
count: function () {
return Counter.findOne().count
}
});
Common:
Counter = new Mongo.Collection('count')
Server:
Meteor.publish('count', function() {
return Counter.find()
})
Meteor.startup(function () {
if(Counter.find().count() === 0) {
Counter.insert({count: 0})
}
Meteor.setInterval(function() {
Counter.update({}, {$inc: {count: 1}})
}, 1000)
});
Example on meteorpad
It depends on how you plan to scale your application. If you plan to scale to multiple server instances then you cannot rely on the servers sharing information automatically. In this case it would be best to create a collection named something like "ApplicationState". Then every instance of your application can use a consistent state, and you can make use of the built in subscriptions.
If you plan to only use a single server instance then you should checkout the documentation on Tracker: http://manual.meteor.com/#tracker. This allows you to defined custom dependencies on data. I have not had the chance to play with it yet, but I am pretty sure that you can create something similar to subscriptions: http://manual.meteor.com/#deps-creatingreactivevalues
Your code does not work as the way you want it because regular plain vars are not reactive data sources. The docs has a list of reactive data sources here http://docs.meteor.com/#/full/reactivity - So for your example to work you'd want to use Session or ReactiveVar - but these only works on the client so they wont help you here.
Your best bet is to create a manual publish function and subscribe to it from the client (or as other people has proposed, use a Collection - which would work across multiple servers as well). Hope that helps!