Hi Jack, No worries! I am working on an updated version, as mentioned in my previous messages, which I think will be much better. Unfortunately, I won't have time to work on it until Thursday at the earliest, though the code in both master and animated-components branches are usable right now.
In the meantime, I will think about your use case - I hadn't really thought about that before now, but I think that is likely a very common use case for animated components. With that said - watch should work. It takes in the cursor and should return a boolean - if true, the animation is started. The code is literally: (when (and watch (watch props)) (async/put! (om/get-state owner :anim-ch) true)) I don't have an example ready to right now (I will write more examples over the weekend), but you should be able to use it like this: (ominate example-component {:watch #(> (:foo %) 10) :duration 5000 :easing ease/sine-in :anim anims/fade) Note however that I have not tested a watch function which continues returning true - I've only tested one which returns true once and then false again. I will test and make sure this works properly in my next release. On 5 May 2014 22:25, Jack Schaedler <jwschaed...@gmail.com> wrote: > HI Daniel, > > Apologies in advance for the probably stupid question: > > My main use case is to animate elements as they enter and leave the Dom. > Something similar to the way that CSSTransitionGroups work, but hopefully > with more of the power you are providing with the easing functions and > timing mechanisms. I just had a go at incorporating the Ominate library > with Goya and I'm not entirely sure about the best way to proceed for this > use case. I tried using the :watch config option, but didn't have much > luck. Should I be explicitly sending a request to trigger the animation via > the channel, or is the watch facility sufficient for this use-case? Do you > have an example of this behavior somewhere I could look at? > > Sorry again, it's late here and my head is starting to swim a bit. Let me > know if the question makes sense! > > > On Monday, May 5, 2014 10:09:53 AM UTC+2, Daniel Kersten wrote: > > Excuse the typos in my previous mail, typing on a phone. > > > > I wanted to add that I think it makes sense to move all of the public > animation state into the child components local state rather than passing > it in as a cursor as IMHO app state should be reserved for domain data > while local state makes sense for transient visual data like animation. > Also, the child will never transact! it (as it would be overwritten next > frame anyway), so a cursor seems unnecessary. > > > > > > I'll make that change to animated-components later. > > > > On 5 May 2014 08:57, "Daniel Kersten" <dker...@gmail.com> wrote: > > > > > > 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" <ddell...@gmail.com> 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 <dker...@gmail.com > > > > > <mailto:dker...@gmail.com>> 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 <ddell...@gmail.com > > > > > <mailto:ddell...@gmail.com>> 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 clojurescrip...@googlegroups.com > > > > > <mailto:clojurescript%2bunsubscr...@googlegroups.com> > > > > > > <mailto:clojurescript+unsubscr...@googlegroups.com > > > > > <mailto:clojurescript%2bunsubscr...@googlegroups.com>>. > > > > > > To post to this group, send email to > > > > > clojur...@googlegroups.com > > > > > <mailto:clojur...@googlegroups.com> > > > > > > <mailto:clojur...@googlegroups.com > > > > > <mailto:clojur...@googlegroups.com>>. > > > > > > 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 clojurescrip...@googlegroups.com > > > > > <mailto:clojurescript%2bunsubscr...@googlegroups.com>. > > > > > To post to this group, send email to > > > > > clojur...@googlegroups.com > > > > > <mailto:clojur...@googlegroups.com>. > > > > > 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 clojurescrip...@googlegroups.com > > > > > <mailto:clojurescript+unsubscr...@googlegroups.com>. > > > > > To post to this group, send email to clojur...@googlegroups.com > > > > > <mailto:clojur...@googlegroups.com>. > > > > > 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 clojurescrip...@googlegroups.com. > > > > To post to this group, send email to clojur...@googlegroups.com. > > > > 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 clojurescript+unsubscr...@googlegroups.com. > To post to this group, send email to clojurescript@googlegroups.com. > 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 clojurescript+unsubscr...@googlegroups.com. To post to this group, send email to clojurescript@googlegroups.com. Visit this group at http://groups.google.com/group/clojurescript.