proof-of-concept animation hooks on devel

[Emily Stark]

Hi everyone,

On devel, we recently added hooks to Blaze that let you override the default behavior when Blaze intends to insert, move, or remove an element in the DOM. For example, you can use these hooks to animate nodes as they are inserted, moved, or removed. To use them, you can set the `_uihooks` property on a container DOM element. `_uihooks` is an object that can have any subset of the following three properties:

* `insertElement: function (node, next)`: called when Blaze intends to insert the DOM element `node` before the element `next`

* `moveElement: function (node, next)`: called when Blaze intends to move the DOM element `node` before the element `next`

* `removeElement: function (node)`: called when Blaze intends to remove the DOM element `node`

Note that when you set one of these functions on a container element, Blaze will not do the actual operation; it's your responsibility to actually insert, move, or remove the node (by calling `$(node).remove()`, for example).

Tom Coleman from Percolate put together a cool example showing how to use them; you can see it here.

As you can see from the underscore in the name, `_uihooks` is not intended to be the final API, but if you start playing around with it, we'd love to know how it's working for you.

[Andrew Mao]

Nice. Meteor will steamroll everything.

[Ry Walker]

Just kicked tires. Love it.

Thanks for demo, Tom.

Truthfully, I'm sort of sad to have seen it — because I want it NOW :)

-Ry

--
You received this message because you are subscribed to the Google Groups "meteor-core" group.
To unsubscribe from this group and stop receiving emails from it, send an email to meteor-core...@googlegroups.com.
To post to this group, send email to meteo...@googlegroups.com.
Visit this group at http://groups.google.com/group/meteor-core.
For more options, visit https://groups.google.com/d/optout.

[Andrew Mao]

You guys mentioned something before where changing the sort order on a cursor would trigger only move events instead of re-rendering the whole list. Is this something that will be integrated into the UI hooks as well?

[Andrew Mao]

I'm not able to see transitions on Tom's example, and I can't get my own example working quite right either.

I've given my own shot at https://github.com/mizzao/CrowdMapper/blob/master/client/views/datastream.coffee#L20. I have a highly concurrent data driven app where users are filtering data, and multiple concurrent deletes without animation mean the scrolling changes constantly and users get confused. Adding animated removal and automated adjustment of scrolling would kill two birds with one stone and solve the issue I raised at https://meteor.hackpad.com/Blaze-Proposals-for-v0.2-hsd54WPJmDV.

It seems that almost everything is working - except the node actually disappears before the fadeOut's complete callback, and then the scroll position is adjusted a little while later. It's as if Blaze is deleting and cleaning up the contents of the node itself. I think what might be happening is that I have something of the form

        {{#each data}}

        {{> dataItem}}

        {{/each}}

where the iterable item is in a separate template. Is there any way to get the UI hooks working with that? I guess I could do a $(node).clone() and operate on that, but it seems quite ugly.

[Andrew Mao]

Nope, that wasn't it. I put the child elements directly within the #each and saw the same behavior. 

I'll be trying to figure this out over the rest of the day. I really want this to work!

[Avital Oliver]

That should already be the case. Is it not?

--

PS. I genuinely *really* like receiving feedback of any kind. Leave it anonymously at http://www.admonymous.com/avital

[Emily Stark]

Andrew, sorry about that -- there was a bugfix branch that we forgot about and never merged to devel. Oops. Try on latest devel now and let us know if you still see the problem.

[Andrew Mao]

YIPPEE-KI-YAY! It works!!

Just another example of the ass-whoopin that Meteor's going to be handing over to those other web frameworks.

[Andrew Mao]

P.S. I should just note that these UI hooks may or may not replace some of the other functionality we've been discussing for Blaze-refactor. I'm sure you guys have a handle on the big picture, but I just thought I'd make sure.

[Gadi Cohen]

Oh wow awesome.  I suddenly feel a lot more powerful :)

I think for many of us this is a very welcome feature... CSS animations on anything except render have been quite a pain until now.  And a few other use cases of course.  Great work!

[Fabian Vogelsteller]

finally my template-animation-helper hack becomes useless :) Or better i can make it work with the new hooks.

[Fabian Vogelsteller]

What would happen if one adds and removes a template very fast? Wouldn't errors occur as he tries to add items in a template which is not in the DOM anymore?

See this demo, when you press the "fade in/out" quick behind each other:

https://templateanimationhelperdemo.meteor.com

 

[Tom Coleman]

Benjamin Richard pushed the transitions package a little further and found an issue with the hooks that I’ve written up here: 

https://github.com/meteor/meteor/issues/2237

--

[Andrew Mao]

I've come up with a package that addresses common transition needs in my app: https://github.com/mizzao/meteor-animated-each

Demo here: http://animated-each.meteor.com/. Comments and feedback welcome!

[Tom Coleman]

Cool stuff Andrew.

One issue with the `_uihooks` as they are currently implement is the need to attach behaviour to a parent element. This means if you want to stop behaviour from “bleeding” to sibling elements, you need to potentially add unnecessary wrapper elements to the DOM.

Would it be possible to decorate an enclosing domrange (or even the view attached to that DR) rather than an actual DOM element? Playing with the Meteor source I can see that the domranges get stripped out of the DOM as an initial step before the element themselves are removed, so there’s no simple way to achieve this, but it seems a more natural place to put the hooks!

[Gabriel Pugliese]

I always wanted to do that Andrew :D Ty for the package!

Gabriel Pugliese
CodersTV.com
@coderstv

[Andrew Mao]

Hi Tom,

When I was making this I originally considered forking from your package, but there were two things that I wanted to do differently:

• It seemed too tricky to try and activate the hooks with a helper as you have done. In particular, if `this.firstNode.parentNode` turns out to be not defined (especially if there are no empty text nodes to grab for firstNode), the hooks would be unreliable - I think this is the way things will work in 0.8.3. So I wanted to just ask for a direct element to attach the hooks to.
• I also wanted things to work out of the box without the need to define CSS transitions for things - or at least have some default transitions that can be overridden. I think transitions would be more efficient for rendering, but I couldn't think of a good way to have defaults that might be overridden later. I'd be up for better ideas for this.

I think your comment about a more robust way to attach hooks is spot on. I'm not an expert on this topic myself, but I'm sure that you, Chris, or MDG will come up with a better system for this before 1.0 :)

[Tom Coleman]

On Monday, 21 July 2014 at 5:25 am, Andrew Mao wrote:

Hi Tom,

When I was making this I originally considered forking from your package

No worries Andrew. I’m not using my package yet anywhere so I don’t consider it production ready yet. But I am hoping to retain the helper syntax.

• It seemed too tricky to try and activate the hooks with a helper as you have done. In particular, if `this.firstNode.parentNode` turns out to be not defined (especially if there are no empty text nodes to grab for firstNode), the hooks would be unreliable - I think this is the way things will work in 0.8.3. So I wanted to just ask for a direct element to attach the hooks to.

Yeah, fair enough. Another reason why the domrange approach makes sense to me.

• I also wanted things to work out of the box without the need to define CSS transitions for things - or at least have some default transitions that can be overridden. I think transitions would be more efficient for rendering, but I couldn't think of a good way to have defaults that might be overridden later. I'd be up for better ideas for this.

Yeah, I’d love to hear ideas about this! I also find it unsatisfying for the reasons you’ve outlined. But I use transitions everywhere for this kind of thing so the package has to do so too :)

[Fabian Vogelsteller]

I just add two packages, which make animation a breeze. They are based on UI._hooks.

One animates using velocityjs the other animates using native CSS3 transitions, please take a look and tell me what you think:

http://atmospherejs.com/package/animation-helper

http://atmospherejs.com/package/animation-helper-velocity