I think there's definitely merit in your suggestion as it allows components to animate themselves, plays nicer with Om and React and potentially will have smoother animation too, but I'm not yet sure what it should look like. I've rewritten ominate to use your approach in the animated-components branch (I'll be pushing an update soon that puts its features almost on par with master, the only thing missing is auto repeating animations). Would love your feedback on it.
Does it really make sense to wrap a component that knows it's being animated in animation logic rather than providing something that can be used internally? It seems odd to require the component consumer to know Scott the nitty gritty animation details when the component itself also has to know about it. On the other hand, I can see a lot of value in using animated components as wrappers to other components that don't know their being animated kind of like om component versions of my existing animation functions. Again would love feedback especially on api design. Over all, I see three types of animation: a component that animates itself internally (eg your example code), a component which is animated that contains sub components (possibly by rendering animated borders or overlays around or over the sub component) and post processing a component by modifying and animating a dom node after rendering (eg, the code in master). I think the code in animated-components could easily address second and third, but as I said above, I'm unsure about how the first should look. I'll give that use case some hammock time :-) Re easing functions - absolutely, go for it! Move them into their own lib if you wish (but note that not all currently work...). I ported them from another library anyway (url in comments in the source). I am wondering if they should be rewritten though. I saw another library which has a set of functions (eg quadratic, cubic, sine etc) and a separate set of functions for ease-in, ease-out, ease-in-out. I already provide composable functions for reversing and such, maybe in/out should simply compose with the interpolation functions too? Seems more flexible. Definitely should be it's own library then, though. On 5 May 2014 03:37, "Dave Della Costa" <[email protected]> wrote: > 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. > -- 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.
