I was more just curious if there was a benefit to one over the other! I can see it potentially being useful to have animations outside of Om/React's control flow--but in that case it would probably make more sense as a separate library.
In any case glad it sparked some ideas. I'll probably put my simpler version out as a simple Om component, since I need something minimal (and I'll probably reference/include your handy easing functions if you don't mind). But I'll keep my eye on ominate to see how it goes...good luck with it! DD (2014/05/05 4:01), Daniel Kersten wrote: > So, I've spent the past 45 minutes thinking about this and here's what > I've come up with: > > * I love the idea of animated components - components that react to a > certain bit of app-state to animate themselves > * I like the idea of animated wrapper components - that is, components > which wrap non-animated components in order to make them animated > (this is essentially what my animation functions do) - things that > cause basic style changes to the components they wrap would fall > into this category (eg, I have a component and I want it to fade to > black - that component doesn't need to know that its being animated). > * I would like to be able to control my components: start, stop, > restart at the very least. > * When starting an animation, it would be nice to be able to override > the configuration > * I want to provide a collection of standard animations that can be > applied to other (non-animated) components > * I want to be able to manually trigger animations, or tie them to > app-state changes > * I want to be able to be notified when the animations complete > * I want to be able to set animations to run once, repeat multiple > times or to loop forever (until I manually stop them) > > To meet these goals, I've started rewriting ominate.core to work similar > to what you wrote and expanding on it. I have still got to think about > how wrapper components should work. The rest should be doable without > too much trouble. > > I'm experimenting with this in the animated-components branch, if you're > interested: https://github.com/danielytics/ominate/tree/animated-components > > > On 4 May 2014 19:09, Daniel Kersten <[email protected] > <mailto:[email protected]>> wrote: > > Honestly, I did what I was familiar with. Your approach is seems better. > > I'm happy to update my implementation to work in a similar fashion. > Can you outline a bit how you envisioned something like this to > work? Any thoughts on desired functionality or API design? > > I threw mine together in a few hours yesterday, so I'm not > particularly attached to it and am happy to incorporate new ideas :) > > > > > > > On 4 May 2014 18:38, Dave Della Costa <[email protected] > <mailto:[email protected]>> wrote: > > Daniel, this is cool and is something I've been thinking about for a > month or so. However I've been prototyping a leaner approach which > leverages Om/React more heavily. > > So following from that I have a question: why create your own timing > loop, rather than use the underlying update mechanism in Om, which > already does the same thing using requestAnimationFrame (for that > matter, I'm also curious why David does it this way here: > > https://github.com/swannodette/om/blob/master/examples/animation/src/core.cljs)? > > This simplifies the code significantly and obviates the need for > specialized animation functions, instead allowing for animation > *components* which seems preferable to me. > > I've got a working implementation of what I'm talking about, > using your > easing functions, here: > > https://github.com/ddellacosta/animation-proto > > DD > > (2014/05/04 9:25), Daniel Kersten wrote: > > Hey everyone, > > > > I've just pushed my little Om project to Clojars and Github :) > > It's still early in development, but I'd love some feedback on > how it > > should progress. > > > > Ominate allows you to animate any Om component by wrapping the > component > > in (ominate ...) before passing it to build, specifying > duration, easing > > function and animation. > > > > https://github.com/danielytics/ominate > > > > --- > > > > Animations are simply functions which take in a value between > 0 and 1 > > and the DOM node of the component being animated and then do > "something" > > to the DOM node (typically changing it's style). Additionally, > > animations may provide begin and end functions which get > applied to the > > DOM node before and after the animation runs, allowing them to > modify > > the node to prepare for the animation and then clean up again > afterwards. > > > > Currently, Ominate is only packaged with two animations: fading > > (changing opacity over time) and color-fading (blending? - > placing a > > color overlay above the component and then fading that). I plan on > > adding many more animations after I've finalized the API. > Right now, > > animations are triggered by putting a value on a channel. > > > > I'm still deciding what the final API should look > like.*Feedback and > > suggestions welcome!* > > > > Some ideas I'm thinking about: > > > > * I would like to allow animations to be triggered by app state > > change, perhaps by passing a cursor to Ominate and a predicate > > function to apply to the cursor - when it returns true, the > > animation is triggered. > > * Ominate should also report animation completion back to > the user - a > > callback passed to (ominate ...) is probably the best way > to do this. > > * It would be cool if different animations can be "sent" to the > > component rather than only supporting preset animations. > > > > > > -- > > Note that posts from new members are moderated - please be > patient with > > your first post. > > --- > > You received this message because you are subscribed to the Google > > Groups "ClojureScript" group. > > To unsubscribe from this group and stop receiving emails from > it, send > > an email to [email protected] > <mailto:clojurescript%[email protected]> > > <mailto:[email protected] > <mailto:clojurescript%[email protected]>>. > > To post to this group, send email to > [email protected] > <mailto:[email protected]> > > <mailto:[email protected] > <mailto:[email protected]>>. > > Visit this group at http://groups.google.com/group/clojurescript. > > -- > Note that posts from new members are moderated - please be > patient with your first post. > --- > You received this message because you are subscribed to the > Google Groups "ClojureScript" group. > To unsubscribe from this group and stop receiving emails from > it, send an email to [email protected] > <mailto:clojurescript%[email protected]>. > To post to this group, send email to > [email protected] > <mailto:[email protected]>. > Visit this group at http://groups.google.com/group/clojurescript. > > > > -- > Note that posts from new members are moderated - please be patient with > your first post. > --- > You received this message because you are subscribed to the Google > Groups "ClojureScript" group. > To unsubscribe from this group and stop receiving emails from it, send > an email to [email protected] > <mailto:[email protected]>. > To post to this group, send email to [email protected] > <mailto:[email protected]>. > Visit this group at http://groups.google.com/group/clojurescript. -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups "ClojureScript" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/clojurescript.
