This code is from the Meteor first app tutorial, and I am a bit confused about the role of the words "task(s)".
In the html file it is the name of a template, which is called by {{> task}}
in <body>
In the js file, it is used to declare a collection:
Tasks = new Mongo.Collection("tasks");
By which is meant "Tasks" is a collection of "tasks"
tasks is also the name of a function in the js file -> tasks: function ()
which returns a list of "tasks" to the html file, where it is called in this way:
{{#each tasks}}
{{> task}}
{{/each}}
It seems the meaning of "tasks" is both the name of a function, and the data tuples it returns. Is that normal? Is this statement in <body> the template "task" is called to format data returned by a function "tasks" that returns a list of "tasks". Is that normal?
html file:
<body>
<div class="container">
<header>
<h1>Todo List</h1>
</header>
<ul>
{{#each tasks}}
{{> task}}
{{/each}}
</ul>
</div>
</body>
<template name="task">
<li>{{text}}</li>
</template>
js file
Tasks = new Mongo.Collection("tasks");
if (Meteor.isClient) {
// This code only runs on the client
Template.body.helpers({
tasks: function () {
return Tasks.find({});
}
});
Agree that the example reuses names, this is quite a common pattern. Perhaps an explanation of each name might help:
Tasks = new Mongo.Collection("tasks");
tasks on the right-hand-side is the name of the mongodb collection. If you go into the mongo shell for example you will see documents in the db.tasks collection
Tasks on the left-hand-side is the name of the collection to be used in javascript in your Meteor app, both on the client and server. A typical use of Tasks will be javascript code such as Tasks.find({})
The tasks which appears in the spacebars template code in your HTML file is quite different.
{{#each tasks}}
{{> task}}
{{/each}}
tasks refers to a template helper function that returns a cursor or array
task refers to an individual Template that you've created in HTML. You can tell it's a template because of the template reference >
You could replace tasks and task in your template with taskList and oneTask and that would be just fine. But you couldn't just start using MyTasks.find() in javascript without renaming your Tasks collection on the left side of the collection assignment.
There's an unofficial convention that mongo collection names are lower case whereas Meteor collection names (in js) are Proper case. Collection names are global variables in js so the Proper case helps distinguish them anyway.
I can see how that is confusing at first and one may prefer a different naming of variables, functions, helpers and collections to avoid confusion. But yeah, the > tasks refers to the template (to be embedded). In the body you need to use #each tasks to refer to the helper function (tasks). So really there are only three items here:
Tasks, the collection holding the data,
tasks, the helper function that makes data from the Tasks collection available to the template engine (referred to in the body using #each tasks),
and task the template that renders a given task.
Related
I have a simple template which has a search box in it:
<template name="search">
<input type="text" name="search" id="search" />
{{> search_results}}
</template>
and obviously, the search results template:
<template name="search_results">
<ul>
{{#each results}}
<li>{{this.resultValue}}</li>
{{/each}}
</ul>
</template>
There is an event for keyp on the search input:
Template.search.events({
'keyup input#search': function (e) {
// fetch result from db
}
});
My problem is, where i have the comment: fetch result from db how do i get the search results template to auto update with the results from the db query?
To be clear: i can get the results fine, just cant see how to get the results template to update.
Essentially, something in the template you want to rerender (search_results) has to be reactive and register a changed event. Out of the box, that means it could be any of the data sources listed here. Since this isn't happening for you, I assume that when you "fetch results from db" you're not actually returning the result of a minimongo query, as this would be reactive by default.
If so, this kind of problem is often most easily solved by rolling your own reactivity using the Deps.Dependency prototype, which (as I understand it) underpins all the other reactive data sources other than the minimongo itself.
If you set var resultsChanged = new Deps.Dependency(), you get an object with two methods: depends and changed. Invoke the former in any computation you want to rerun when it changes and the latter to register a change. Session variables are basically just key/value stores with these Deps.Dependency methods attached to their get and set methods respectively.
So if you have resultsChanged initialised, you just need to make sure your search_results template depends on it, either by adding a new helper function (if results is in the data context as opposed to being a call to a helper), or amending the results helper itself. I'll assume the latter, but adding a new helper instead would be equally trivial.
Template.search_results.helpers({
results: function() {
resultsChanged.depend();
// get your results from wherever
return results;
}
});
That will rerun every time resultsChanged changes, so you just have to add the appropriate code in your callback when you fetch the results:
'keyup input#search': function (e) {
// fetch result from db, passing "resultsChanged.changed()" in a callback
}
Obviously, if the result fetching is synchronous, you don't even need to pass a callback, you can just do it on the next line.
I hope that is vaguely helpful - please let me know if it's not. If my assumption that you're not just pulling something out of the database is wrong, then this is probably on totally the wrong track, so I would recommend posting your actual "fetch result from db" code in your question.
I've got a Newsfeed idea that I wanted to build with Meteor, but I'm having a bit of a struggle figuring out how to make the news feed itself constant, that is not reactive, but update the sub-items (comments, likes, etc) as soon as they're updated.
I've got everything stored in a single collection, and I'd like to keep it that way if possible. So the collection is setup like this:
[
{
title: 'A random title',
date_created: '01/01/2001',
comments:
[
{'message': 'Lorem ipsum', date_created: '01/01/2001'},
[...]
]
},
[...]
]
So what I'd like to do is have the newsfeed non-reactive, so that when a new news item is inserted or updated, the template holding the list of news won't get re-rendered. But if a comment is added, deleted, or someone likes the news feed, I'd want that to get updated right away in the template.
I've been trying to figure out how to use {{#isolate}} and {{#constant}} but to no prevail.
Here's my client side JS:
Template.group_feed.feed_data = function() {
var feed = Newsfeed.find({}, {
sort: {updated_time: -1},
limit: 10,
reactive: false
}).fetch();
return feed;
};
I set reactive: false so that it doesn't update the template, but that makes it static also when comments or likes are updated. So I'm guessing there's a better way to do this then to make the whole collection non-reactive.
Here's my template code:
<template name="group_feed">
<div id="feed-wrapper">
<ul>
{{#each feed_data}}
{{> group_feed_item}}
{{/each}}
</ul>
</div>
</template>
<template name="group_feed_item">
<li>
<h1>{{title}}</h1>
<div class="comments">
{{#each comments}}
<p>{{message}}</p>
{{/each}}
</div>
</li>
</template>
Anyone got a nice way of achieving this?
You have two options here. (I'll use coffeescript for my pseudocode)
use observeChanges:
NewsCursor = NewsItems.find()
NewsCursor.observeChanges
changed: (id, fields) ->
if fields.comments
Session.set ("commentsForId"+id), fields.comments
Split your data into two collections: one for the posts and one for the comments.
If you don't do one of those, {{isolate}} isn't going to help you. With your current data setup, Meteor just sees whether the post changed or not, and updates any templates when it does; it doesn't keep track of which part changed.
I did not test it, but I guess it would be most straightforward to limit the subscription of the client, thus reducing data transfer an eliminataing the need for the preserve:
it would be something like:
on server:
Meteor.publish('tenItemsBefore',function (time) {
Newsfeed.find({updated_time: {$lt time}}, {
sort: {updated_time: -1},
limit: 10
})}
on client, in reactive context eg. in Meteor.autorun():
Newsfeed.subscribe('tenItemsBefore',Session.get('lastUpdate'));
on client, triggered by an event eg. refresh using router package:
Session.set('lastUpdate', (new Date()).getTime());
hope that helps,
best, Jan
I'm pretty sure the problem is that you are returning an array rather than a cursor.
It seems that Spark behaves differently with the two.
Remove the .fetch() from the end of the feed query.
For more information about how this stuff works, I would strongly suggest looking at Chris Mather's great presentations at http://www.eventedmind.com/
Specifically, the one on reactivity in slow motion illustrates the difference between an array and a cursor:
http://www.eventedmind.com/posts/meteor-ui-reactivity-in-slow-motion
UPDATE: In my original answer I didn't fully understand problem - my apologies, so the bit about removing the fetch() will not help you. Here are a couple of options you might want to explore:
Using the Meteor.observe or Meteor.observeChanges to watch for changes to the comments field and updated the DOM with code ('by hand').
Create a custom collection on the server side that publishes just the comments from your original collection. So I'm not suggesting you change the data model as stored in mongo, just publish a different view of it. With this way it might be easier to continue to use templates to update the comments.
After initial loading of the collection, make a note of the viewed item ids, and then subscribe to the collection passing a list of ids to watch (or date range). This would require a new publish function that took a array of ids, and filtered the returned documents. This approach would prevent new documents disturbing what you had on screen, and you would still get comment changes, but you would also get deletions and field changes that affected non-comment fields.
Hopefully one of these approaches may fit the bill for you.
In case for some reason you don't want / cannot restrict the data seen by the client with publish or if new posts with earlier post time could be inserted and destroy the preservation the above solution wont work.
Therefore I suggest a different solution to more directly achieve preservation:
On opening the posts save the _id's of the watched posts in a non reactive way as by:
Session.set('watched',
_.map(
Newsfeed.find({}, {
sort: {updated_time: -1},
limit: 10,
reactive: false //not sure wheather you need both, as #StephenD
}).fetch(), // pointed out sth. fetched is non reactive by default
function (obj) {return obj._id;}
)
);
and:
Template.group_feed.feed_data = function () {
return Session.get('watched');
};
Template.group_feed_item.item = function () {
return Newsfeedd.findOne(this);
};
as well as a small update in the html (where with saves you from definining an extra template):
<template name="group_feed_item">
<li>
{{#with item}}
<h1>{{title}} - {{_id}}</h1>
<div class="comments">
{{#each comments}}
<p>{{message}}</p>
{{/each}}
</div>
{{/with}}
</li>
</template>
best, Jan
From the docs (emphasis mine) - http://docs.meteor.com/#find
Cursors are a reactive data source. On the client, the first time you
retrieve a cursor's documents with fetch, map, or forEach inside a
reactive computation (eg, a template or autorun), Meteor will register
a dependency on the underlying data. Any change to the collection that
changes the documents in a cursor will trigger a recomputation. To
disable this behavior, pass {reactive: false} as an option to find.
Note that when fields are specified, only changes to the included
fields will trigger callbacks in observe, observeChanges and
invalidations in reactive computations using this cursor. Careful use
of fields allows for more fine-grained reactivity for computations
that don't depend on an entire document.
Actually, I am looking for methods that let the View be responsible for marking the first or the last item in a collection view, and I found this one How do I add a separator between elements in an {{#each}} loop except after the last element?
.But I don't want to define itemViewClass template's attrs(classNames for example) in javascript, can I just use a {{itemView}} helper or something to define a itemView template?
{{#collection contentBinding="dataList" tagName="ol" classNames="list" itemViewClass="ItemView"}}
{{#itemView classNames="item" classNamesBinding="isLastItem:last"}}
item templates
{{/itemView}}
{{/collection}}
Although, this can be solved in another ways, I just want to know if I can find a built-in support. And I do search for a long time, just can't find Ember.Handlebars.collection's document, it's not in the latest API doc.
starting with the master version of Emberjs, you may try using a custom Handlebars "bound" helper.
it would look something like this :
{{#each item in collection}}
{{#isLastElement item}}
template if last
{{else}}
template if not
{{/isLastElement}}
both templates
{{/each}}
Ember.Handlebars.registerBoundHelper('islastElement',
function(item, options) {
if(functionTellingIfThisIsLastElement(item))
return options.fn(this);
else
return options.inverse(this);
}
);
This is just another way to see things, with functionTellingIfThisIsLastElement either looking in the collection or a property in your item. To access the collection you would have to change some stuffs here, to get the good context + parameters, depending on your code.
When a meteor app is deployed on server, it takes a considerable amount of time (3-4 seconds) for the data to be fetched from mongodb. In my app, I have a template that is bound to data through an #each block helper.
{{#each items}}
{{> item_info}}
{{else}}
No items yet.
{{/each}}
So when the app loads in a new browser session, users see the message No items yet till the time data has finished loading. When data becomes available, that message gets replaced with the actual data. But this results in a bad user experience because some users actually think, for those 3-4 seconds, that they have lost their data.
My question is -- is it possible to change that "else" message to something like "Loading..." while data is being fetched? Or is there a more elegant solution to this problem?
Thanks.
I think you should use Session with onComplete() function inside the Meteor.subscribe()
This will executed automatically when the subscription is completed, i.e ur collections are completed loading on client.
For Eg.
Meteor.subscribe('yourCollection', function onComplete(){
// set a session to true indicating your collection is loaded.
Session.set('itemsLoaded', true);
});
Then call your template helper based on the session value as:
Template.yourTemplate.isLoaded = function(){
return Session.get('itemsLoaded');
}
And your html will look like:
<template name="yourTemplate">
{{#if isLoaded}}
{{#each items}}
{{> item_info}}
{{/each}}
{{/if}}
{{#unless items}}
<img src="images/loader.gif">
{{/unless}}
</template>
Reading about the different Spark annotation types here: https://github.com/meteor/meteor/wiki/Spark
I am still confused on where Landmarks and Branch Labels need to be placed. What's the difference between the two, and when does Handlebars call them? I am the author of the Blade templating engine, and I am trying to integrate Blade with Spark.
In Handlebars, every template and every {{#constant}}...{{/constant}} region is wrapped with a landmark. When a region of the DOM is reactively updated, the old and new landmarks are matched for the purpose of DOM preservation, lifecycle callbacks (created/destroyed), and landmark-local state.
Landmarks are identified by the "path" formed by the branch labels that contain them. (Landmarks themselves don't contribute to the path.) It's illegal to have two landmarks with the same path. It's also important that you compute the HTML that will go inside the labeled region or the landmark from the body of the function argument to labelBranch or createLabel. This is because Spark is actually already matching the DOM when you call these functions so that it knows whether to call "created" (because this is a new landmark) or not (because it is a re-rendering of an old one) before running the function to calculate the HTML.
Handlebars calls labelBranch in several places to distinguish any template (landmark) invocations that should be distinct. Basically, the labels should determine the "call stack" that led to the template invocation. Each template invocation in the template source ({{> someTemplate}}) gets a label, and loops are also instrumented, labeling each iteration of the loop based on the _id of the object in question or some other heuristics if there isn't one. (Note that there are two code paths for loops in Meteor templating, one for observable cursors from the database and one for everything else, like normal arrays.)
In this snippet from a template that includes the "foo" template several times, each invocation of "foo" (including each iteration of the loop) is done within a different branch label:
{{> foo}}
{{> foo}}
{{#each collection}}
{{> foo}}
{{/each}}
{{> foo}}
What if a helper invokes template functions directly?
var myHelper = function () {
return Template.foo() + " " + Template.bar();
}
In this case, the day is saved because the template package also wraps each template in a label like "Template.foo" or "Template.bar" (labels are cheap). However, there will be a duplicate landmark problem if a helper calls the same template multiple times with different arguments; in this case, it is up to the helper to drop additional branch labels to disambiguate.
The implementation of Template.foo that is generated by the templating package (in deftemplate.js) uses the following nested annotations, from outer to inner: label, data, landmark, events, isolate. This order is pretty constrained. For example, the landmark enclosing the events annotation is used to find the data. The isolate annotation is intentionally on the inside.
The current factoring of the handlebars and templating packages may not be great for adding additional templating packages! This is a new frontier for us. We're very interested in having more templating languages, though, and happy that you're working on this.