Animating new objects in a subscription

I have googled around for tips on how to animate new objects that appear in a list controlled by a subscription and an {{#each}}.

There are some blog posts/faqs/Google Group posts, but they are all from 2012 or 2013… and the present Meteor world is rather different. So what is an up to date way of achieving this?

Basically I want to show new objects in the list in a different color for a short while, and then have them crossfade to the normal color.

https://groups.google.com/forum/#!msg/meteor-core/1kUoG2mcaRw/FxVRqib4izUJ






3 Likes

So everyone is using _uihooks, based on two brief Groups post on the thing? It seems useful, if it was documented somewhere, but there is no mention of it on the 1.0.4.2 documentation?

Yes use ui hooks for the time being. They haven’t documented it because they haven’t decided if that’s the best way to do it. There’s a blurb on it somewhere on the History.md file. They will eventually make it official.

It seems though that ui hooks are global? When I define a ui_hook it seems to be applying to every template. I’ve done it like they described in the discover meteor book. It seems that when I define one ui_hook within template.foo.rendered the ui_hook gets applied to every template.

That doesn’t sound right. Can you show us code?

Does the foo in your template.foo.rendered happen to be body or some other global or top-level DOM element? As I recall, the ui_hooks will cascade based on typical javascript behavior.

OK, the thread is hijacked anyway so I might as well introduce a new question :slight_smile: : If I want different animations depending on wether a particular insertElement call is due to a reactive database update (for me typically a small incremental update) or if it is a change in the Session variables that the Template helper is dependent on (typically a total change of the content of the collection), how do I know inside the insertElement: function(node, next) {} code what the cause of the update was???

The only super ugly hack I can think of is to store a timestamp for the collection.find() when it is run in the helper, and then do different animations depending on wether the insertelement is called during the first seconds after the find or if it comes later…

Sorry, this was an error on my side. I didn’t expect a typo error since usually meteor doesn’t even start up when there’s a syntax error. It must have still executed the ui hooks but did it globally since it stopped in the middle of the hook and must have ignored either templare rendered or this.find(…)